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Abstract 


This manual describes the installation and execution of FUN3D version 12.8, 
including optional dependent packages. FUN3D is a suite of computational 
fluid dynamics simulation and design tools that uses mixed-element unstruc- 
tured grids in a large number of formats, including structured multiblock 
and overset grid systems. A discretely-exact adjoint solver enables efficient 
gradient-based design and grid adaptation to reduce estimated discretization 
error. FUN3D is available with and without a reacting, real-gas capability. 
This generic gas option is available only for those persons that qualify for its 
beta release status. 
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About this Document 


This manual is intended to guide an application engineer through configura- 
tion, compiling, installing, and executing the Fun3D simulation package. The 
focus is on the most commonly exercised capabilities. Therefore, some of the 
immature or rarely exercised capabilities are intentionally omitted in the in- 
terest of clarity. An accompanying document that provides example cases is 
under development. 

Release of the generic gas capability is restricted because of International 
Traffic in Arms Regulations (ITAR), so Fun3D usually distributed with the 
generic gas capability disabled. See section 1.4 for details. This manual de- 
scribes Fun3D with and without the generic gas capability, denoted eqn_type= 
'generic' . Features that are specific to an eqn.type are explicitly indicated. 

This document is updated and released with each subsequent version of 
Fun3D. In fact, a significant portion is automatically extracted from the 
Fun3D source code. If you have difficulties, find any errors, or have any 
suggestions for improvement please contact the authors at 

Fun3D-Support@lists . nasa . gov 

We would like to hear from you. 
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Quick Start 

This section takes you from source code tarball to a rudimentary flow so- 
lution using single processor execution on a typical Unix-style environment 
(e.g. Linux, Mac® OS) with a Fortran compiler and the GNU Make utility. 
Fun3D is most commonly executed in parallel, but the intent here is to pro- 
vide the most basic installation, setup, and execution of the Fun3D flow solver 
without the complexity of any third-party libraries or packages. 

See section 1.4 for instructions on obtaining the Fun3D source code tarball. 
Once you have it, unpack the source code tarball, configure it for your system 
(section A), compile it, and add the executables directory to your search path. 
For C Shell, e.g., 

tar zxf fun3d-12 . 8-* . tar .gz 
cd fun3d-12.8-* 
mkdir _seq 
cd _seq 

../configure — pref ix=$-[PWD} 
make install 

setenv PATH ${PWD}/bin : ${PATH} 
cd . . 

For Bourne Shell, the setenv command is export PATH=${PWD>/bin : ${PATH}. 
The change to the PATH environment variable can be made permanently by 
adding the setenv or export command to your shell start up hie. Next, move 
to the doc/quick_start directory, 

cd doc/quick_start 

where you will find a very coarse 3D wing grid (inv_wing.fgrid) intended for 
inviscid how simulation (section 4). Also in this directory are the associated 
boundary conditions hie inv_wing.mapbc (section 3) and a Fun 3D input hie 
fun3d.nml in Fortran namelist format (section B.4). 

Execute the how solver (section 5.1) by running the command 

nodet 

This should produce screen output similar to 

1 FUN3D 12 . 6-exported Flow started 02/11/2015 at 09:58:06 with 1 processes 

2 Contents of fun3d . nml file below 

3 &project 

4 project_rootname = 'inv_wing' 

5 / 

6 &raw_grid 

7 grid_format = 'fast' 

8 data_format = 'ascii' 

9 / 

10 &governing_equations 

11 viscous_terms = 'inviscid' 


ll 


12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 


171 

172 

173 

174 

175 

176 

177 

178 

179 

180 
181 


/ 

&ref erence_physical_properties 
mach_number = 0.7 
angle_of _attack = 2.0 

/ 

&code_run_control 

restart_read = 'off' 

steps = 150 

stopping_tolerance = 1.0e-12 

/ 

&global 

boundary_animation_f req = -1 

/ 

&boundary_output_variables 
number_of .boundaries = -1 
boundary _1 i st ='2,7-8' 

/ 

Contents of fun3d . nml file above 

... opening inv_wing. f grid 

... nnodesg: 6309 ntet: 35880 ntface: 1392 


cell 

statistics : 

type. 

min volume. 

max volume , 

max face angle 

cell 

statistics : 

tet , 

0.38305628E-05, 

0.14174467E+02, 

143.526944837 

cell 

statistics : 

all. 

0 . 38305628E-05 , 

0.14174467E+02, 

143.526944837 


... Constructing partition node sets for level-0... 35880 T 

. . . Edge Partitioning .... 

. . . Boundary partitioning. . . . 

. . . Reordering for cache efficiency. . . . 

. . . Write global grid information to inv.wing . grid.inf o 
... Time after preprocess TIME/Mem(MB) : 0.24 105.83 105.83 

NOTE: kappa.umuscl set by grid: .00 


Grid read complete 

y-symmetry metrics modif ied/examined: 1102/1102 


Iter density.RMS density.MAX 

1 0 . 611767950151108E-04 0 . 68431E-03 

Lift 0 . 766897440658845E-01 

2 0 . 338742957 16 18 17E-04 0 . 11225E-02 

Lift 0 . 736351745655775E-01 


X-location Y-location Z-location 
0 . 25001E-01 0 . 43479E-01 0 . 00000E+00 

Drag 0 . 352117344941344E-01 
0 . 41388E+01 0 . 24706E+01 -0 . 21321E+01 

Drag 0 . 197314403024535E-01 


61 0 . 195396020267687E-12 0.77530E-11 0.21669E+01 0.00000E+00 0.65000E+01 

Lift 0 . 8096 19820 18742 IE-01 Drag 0 . 108249842008451E-01 

Writing inv.wing. f low (version 11.8) lmpi_io 2 
inserting current history iterations 61 
Time for write: .0 s 


Writing boundary output: inv_wing_tec_boundary.dat 
Time step: 61, ntt: 61, Prior iterations: 0 
Done . 


If Fun3D completed successfully, a Mach 0.7 inviscid flow over a very 
coarse representation of an ONERA M6 semi-span wing [1] at two degrees 
angle of attack is available. If not, please refer to Troubleshooting on page 330. 

With visualization software capable of reading Tecplot™ hies, you can visu- 
alize various surface quantities with inv_wing_tec_boundary.dat as shown by 
the pressure contours in Fig. 1. Iterative convergence history can be plotted 


12 



Figure 1: Mach 0.7 flow about a coarse ONERA M6 semi-span wing at 2 
degrees angle of attack. 

from inv_wing_hist.dat as shown in Fig. 2. Histories of all five conservation 
equation residual norms are denoted R_1 -R_5, and the lift coefficient conver- 
gence history is denoted C_L. 
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Figure 2: Iterative convergence history for coarse ONERA M6 wing. 
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1 Introduction 


Fun 3D began as a research code in the late 1980s. [2] The code was created 
to develop new algorithms for unstructured-grid fluid dynamic simulations 
of incompressible and compressible transonic flows. The project has since 
grown into a suite of codes that cover not only flow analysis, but adjoint-based 
error estimation, mesh adaptation, and design optimization of fluid dynamic 
problems extending into the hypersonic regime. [3] 

Fun3D is currently used as a production flow analysis and design tool to 
support NASA programs. Continued research efforts have also benefited by the 
improvements to stability, ease of use, portability, and performance that this 
shift to simultaneous support of development and production environments has 
required. These benefits also include the rapid evaluation of new techniques 
on realistic simulations and a rapid maturation of experimental techniques to 
production-level capabilities. 


1.1 Primary Capabilities and Features 

The primary capabilities of Fun 3D are: 

• Parallel domain decomposition with Message Passing Interface (MPI) 
communication for distributed computing 

• Two-dimensional (2D) and Three-dimensional (3D) node-based, finite- 
volume discretization 

• Thermodynamic models: perfect gas (compressible and incompressible) 
and thermochemical equilibrium, and non-equilibrium 1 

• Time-accurate options from first- to fourth-order with temporal error 
controllers 

• Upwind flux functions: flux difference splitting, flux vector splitting, 
artificially upstream flux vector splitting, Harten-Lax-van Leer contact, 
low dissipation flux splitting scheme, and others 

• Turbulence models: Spalart-Allmaras, Menter k-omega SST, Wilcox k- 
omega, detached eddy simulation, and others, including specified or pre- 
dicted transition 

• Implicit time stepping where the linear system is solved using either 
point-implicit, line-implicit, or Newton-Krylov (multigrid is also under 
active development) 


1 The multi-species, thermochemical non-equilibrium capability requires the high-energy 
physics library, which is only made available upon specific request and under certain condi- 
tions, see section 1.4 for details. 
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• Boundary conditions for internal flows and propulsion simulation includ- 
ing inlets, nozzles, and system performance 

• Grid motion: time- varying translation, rotation, and deformation includ- 
ing overset meshes and six degrees of freedom trajectory computations 

• Adjoint- and feature-based grid adaptation 

• Gradient based sensitivity analysis and design optimization via hand- 
coded discrete adjoint for reverse mode differentiation and automated 
complex variables for forward mode differentiation 

Before exploring more advanced applications (e.g., grid adaptation, moving 
grids, overset grids, design optimization), the user should become familiar with 
Fun3D’s basic flow solving capabilities and have appropriate computational 
capability available as indicated in the next section. 


1.2 Requirements 

The Fun 3D development team’s typical computing platform is Linux clusters; 
so this is the most thoroughly tested environment for the software. A number 
of users also run on other LINIX-like environments including Mac OS X M ; these 
platforms are supported as well. Users have also run on other architectures 
such as Microsoft Windows™-based PC’s; however, the team cannot provide 
explicit support for these environments. 

The user will need GNU Make and a Fortran compiler that supports at 
least the Fortran 95 standard. During configuration, the Fortran compiler is 
tested, and any newer Fortran features or extensions are detected are used 
to the greatest extent possible. A large number of compilers are tested by 
an automated build framework, including Intel®, Portland Group®, NAG®, 
Lahey/Fujitsu®, Cray®, Absoft®, IBM®, GFortran, and G95. 

While the code can be compiled to run on only a single processor, as demon- 
strated in the Quick Start section, most applications will require compiling 
against an MPI implementation and one of the supported domain decomposi- 
tion libraries to allow parallel execution. 

The flow solver uses approximately 2.4 kilobytes of memory per grid point 
for a perfect gas RANS simulation with a loosely-coupled turbulence model. 
For example, a grid with one million mesh points would require approximately 
2.4 gigabytes of memory. Memory usage will increase slightly with the in- 
crease in the number of processors because of the increasing boundary data 
exchanged. Different solution algorithms and co-visualization options will also 
require additional memory. Typically, one CPU core per 50,000 grid points is 
suggested, where a 3D mesh of 20 million grid points would require 400 cores. 
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1.3 Grid Generation 


Fun3D has no grid generation capability. For internal development at NASA, 
the most common sources of 3D grids are VGRID (ViGYAN, Inc. and NASA 
Langley), SolidMesh/AFLR3 (Mississippi State), Pointwise (Pointwise, Inc.), 
and GridEx (NASA Langley). 

For 2D grids, the development team normally uses the AFLR2 software 
written by Prof. Marcum et al. at Mississippi State University Center for 
Advanced Vehicular Systems (CAVS) SimCenter. Scripts are available to fa- 
cilitate the use of this grid generator, but the generator itself must be obtained 
from Prof. Marcum. BAMG [4] is also used for 2D grid generation and adap- 
tation. 


1.4 Obtaining Fun3D 

Fun3D is export restricted and can only be given to a “U.S. Person,” which 
is a citizen of the United States, a lawful permanent resident alien of the U.S., 
or someone in the U.S. as a protected political asylee or under amnesty. The 
word “person” includes U.S. organizations and entities, such as companies or 
universities, see 22 CFR §120.15 for the full legal definition. Release of the 
high-energy, real-gas capability is further restricted because of International 
Traffic in Arms Regulations (ITAR). 

To request the Fun3D software suite, which will include the REFINE grid 
adaptation and mesh untangling library and the KNIFE cut-cell library, please 
use the website request form available at 

http : //f un3d.larc.nasa. gov/chapter- l.html#request_f un3d 

or send an email to Fun3D-Support@lists . nasa . gov containing the following 

information: 

• “U.S. person” to put on agreement form, i.e. , an institution or individual 

• Point of contact (if “U.S. Person” is not an individual) 

• Point of contact email address 

• Phone number, extension 

• FAX number (if available) 

• Address (PO boxes not allowed) 

• Proposed application 2 (optional) 

• How did you discover Fun 3D? (optional) 

2 The high-energy physics library that allows multiple species and non-equilibrium chem- 
istry are only included upon specific request— be sure to note that you desire access to 
this beta functionality as part of your application. Please include the phrase, “requesting 
high-energy gas libraries” . 
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We will forward your email to initiate a review by Langley software release 
authority (SRA) that verifies you qualify as a “U.S. Person.’' Depending on 
the SRA’s backlog, you will be sent a software usage agreement form in a 
week or two. Once a completed usage agreement form is received and the 
SRA notifies the Fun3D support team, the Fun3D support team will make 
arrangements for transfer of the Fun3D software suite. 
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2 Conventions 


This chapter discusses the coordinate system orientation and nondimension- 
alization used by Fun 3D. The nomenclature for this section is 


a 

C 

e 

f 

h 

k 

L 

M 

P 

R 

Re 

t 

T 

U , V, w 
x,y,z 
a 

P 

7 

P 

P 


Speed of sound 
Sutherland constant 
Energy per unit mass 
Frequency 

Enthalpy per unit mass 
Thermal conductivity 
Length 
Mach number 
Pressure 
Gas constant 
Reynolds number 
Time 

Temperature 

Cartesian components of velocity 

Cartesian directions 

Angle of attack 

Angle of sideslip 

Heat capacity ratio 

Viscosity 

Density 


where an asterisk (*) denotes a dimensional quantity. A subscript ref denotes 
a reference quantity. For fluid variables, such as pressure, ref usually corre- 
sponds to the value ‘at oo’ for external flows or another condition for internal 
flows. The units of various reference quantities must be consistent. For exam- 
ple, if the reference speed of sound is defined in feet/sec, then the dimensional 
reference length, L* re j, must be in feet. In what follows, L re f is the length in 
the grid that corresponds to the dimensional reference length, L* re f ; L re f is 
considered dimensionless. 

Fun3D’s angle of attack, sideslip angle, and associated force coefficients 
are based on a body-fixed coordinate system: 

• positive x is toward the back of the vehicle; 

• positive y is toward the right of the vehicle; and 
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• positive z is upward 

as shown in Fig. 3. This differs from the standard wind coordinate system by 
a 180 degree rotation about the y axis. The a and (3 flow angle conventions 
are shown in Fig. 4. 



Figure 3: Fun 3D body coordinate system. 


Z 



Figure 4: Fun 3D freestream flow angle definition. 


2.1 Compressible Equations 

x = x* / (L* re f/ L ref ) 

y = y / (L ref /Lref) 

z = z* / (L* ref /L ref ) 
t = t*a* ref / (L* ref / L re f) 


P = P* / P* ref Pref = 1 
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IVI 

= \V*\/a* ref 

\vL, 

= M re f 

u 

= u* / a* ref 

Href 

= M re f cos a cos P 

V 

= V*/ a* ref 

Href 

= —M re f sin (3 

w 

= W* / a* ref 

W r ef 

= M re f sin a cos /3 

p 

= P*/(P* relief) 

Pref 

= 1/7 

a 

= a* / a* ref 

d r ef 

= 1 

T 

= T*/T* re f 

T re f 

= 1 

e 

= Z*/( P \efa* 2 ref) 

H-ref 

= l/( 7 (7-l)) + M r 2 e/ /2 


To see how the nondimensional Navier-Stokes equations that are solved 
in Fun 3D are obtained from their dimensional counterparts, it is sufficient 
to look at the unsteady, one-dimensional equations for conservation of mass, 
momentum, and energy: 


dp* d(p*u*) 
dt* dx* 


d(p*u*) d 

dt* dx* 



4 „du* 
3^ dx* 


0 


de* 

dt* 


d 

dx* 


(e*+p*)u* 



dT* 

k*—— 

dx* 


0 


where k* is the thermal conductivity. For a thermally and calorically perfect 
gas, we also have the equation of state, the definition of the speed of sound, 
and the specific heat relation: 


a 


*2 


Vn T C v 


T* = P * 

p*R* 

7 R*T * (7 = c p */c v *) 

R* R* / c p * = (7 - l)/7 


The laminar viscosity is related to the temperature via Sutherland’s law 


p 


* 


P ref 


T * i 

ref + <-y 

T* + C* 



3/2 


where C* = 198.6°R for air. 

Substitution of the nondimensional variables defined above into the equa- 
tion of state and the definition of the speed of sound gives: 


T 



P 
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Sutherland’s law in nondimensional terms is given by 


= 1 + C*/T* ref 3/2 
h T + C */T* ref 

where C* is the Sutherland constant ( C * = 198. 6°R for air) and where T* re f 
is in degrees Rankine. 

Substitution of the dimensionless variables into the conservation equations 
gives, after some rearrangement, 

dp d{pu) = 
dt dx 


d(pu ) 
dt 


d_ 

dx 


pu +p~- 


4 Mr., 


ref du 

3 ReL dx 


e f 


= 0 


de 

dt 


d_ 

dx 


(e + p)u — - 


4 M re f du 


M, 


3 ReL. 


-pu 


ref 


dT 


p- 


ref 


dx Re Lr P r ( 7 - 1) dx 


= 0 


where P r is the Prandtl number (generally assumed to be 0.72 for air) 


Pr = 



k* 


and where ReL ref , the Reynolds number per unit length in the grid, corre- 
sponds to the input variable reynolds_number in the fun3d.nml hie. ReL ref is 
related to the Reynolds number characterizing the physical problem, ReL* ref 
by 


ReL , — 

^ ref 


P*ref\V*\ re f( L *ref/L re f) _ P \ ef \ V% ef L\ ef 1 


P 1 ref 


P ref 


J ref 


ReL % 


J ref 


2.2 Incompressible Equations 

x = x* / [L* ref ! L ref ) 

V = y / (L ref / L re f) 

z = z*/(L* ref /L ref ) 
t =t*\V*\ ref /(L* ref /L ref ) 


|E| 

= \v’W\ reI 

\VLf 

= l 

u 

= v/in,,, 

Uref 

= cos a cos (3 

V 

= «•/ lv"L, 

V ref 

= — sin f3 

w 

= <» 7 |r-| re/ 

W r ef 

= sin a cos f3 

p 

= V'/(P\et\ V '\lel) 

Pref 

= 1 
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For incompressible flows, Fun 3D does not model any heat sources. The 
temperature T* is constant and so is the viscosity /T. After dividing through 
by a constant reference density, the one-dimensional continuity and momentum 
equations are: 

du* _ 
dx* 


du* <9 [ , 2 p* 4p* ref du*] n 

( u H — — — = 0 

dt* dx* [ p* ref 3 p* re j dx* 

The fundamental difference between the nondimensionalization of the com- 
pressible equations and the incompressible equations is that the sound speed 
is used in the former and the flow speed in the latter. Substitution of the 
dimensionless variables defined above into the conservation equations gives, 
after some rearrangement, 

du 

dx 


du d 2 4 1 du 

dt ^ dx U ^ 3 Re L , dx 

L J-Jref J 


0 


where, exactly the same as in the compressible-flow path, the Reynolds number 
per unit length in the grid is 


P%e,\ V'LP’re, Re L% „ 

P* ref L re f 


2.3 Generic Gas Equations 

The generic gas path requires all reference quantities (velocity, density, temper- 
ature) be entered in the meter-kilogram-second (MKS) system. The transport 
property nondimensionalization includes the effects of rescaling using the grid 
length conversion factor. The nondimensionalization of other flow variables 
follows the practice used to derive the Mach number independence principle. 
Neither Mach number nor Reynolds number can be used to define reference 
conditions; these are derived from the fundamental reference quantities. The 
derived Reynolds number is relative to a one meter reference length. Tem- 
perature is never non-dimensionalized; it always appears in units of degrees 
Kelvin. 


p 

= P* / P* ref 

Pref 

[kg/nr 

u 

= U* IV* ref 

K, 

[m/s] 

V 

= V* IV* re f 

rn* 

1 ref 

[K] ' 

w 

= W* / V* ref 

T* 

L ref 

M 
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a = a* /V* re f 

P = P*/(p*refV* 2 ref) 
e = e* /V*l ef 
h = h* /V* 2 ref 
P =P*(T*)/p* ref v; ef L* ref 

2.4 Unsteady Flows 

One of the challenges in unsteady flow simulation is determining the nondi- 
mensional time step At. The number of time steps at that At necessary to 
resolve the lowest frequency of interest will impact the cost of the simulation 
and too large a At will corrupt the results with temporal errors. Time is 
non-dimensionalized within Fun3D by 

t = t* a* re f / (L* re f / L re f ) (compressible) 

t = t*\V*\ ref /(L* ref /L ref ) (incompressible) 

where, as in the previous sections, quantities denoted with * are dimensional. 

In all unsteady flows, one or more characteristic times t* c h. r may be identi- 
fied. In a flow with a known natural frequency of oscillation (e.g., vortex shed- 
ding from a cylinder), or in situations where a forced oscillation is imposed 
(e.g., a pitching wing), a dominant characteristic time is readily apparent. In 
such cases, if the characteristic frequency in Hz (cycles/sec) is f* chr , then 

t*chr = 1/F ch r 

In other situations, no oscillatory frequency may be apparent (or not known 
a priori). In such cases, the time scale associated with the time it takes for 
a fluid particle (traveling at a nominal speed of \V*\ re j) to pass the body of 
reference length L* re f is often used: 

t* chr = L\ ef /\V*\ ref 

The corresponding nondimensional characteristic time is therefore given by: 

tchr t chr® ref l re//-^re/) (compressible) 

tchr = t* chr \V*\ re f/(L* re f/L re f) (incompressible) 

Once the nondimensional characteristic t c j ir is determined, the user must 
decide on an appropriate number of time steps ( N ) to be used for resolving 
that characteristic time. Then the nondimensional time step may be specified 
as: 

A t = t chr / N 

The proper value of N must be determined by the user. However, a reasonable 
rule of thumb for second-order time integration is to take N = 200. Note that if 
there are multiple frequencies requiring resolution in time, the most restrictive 
should be used to determine At. 


24 



2.5 Turbulent Flows 


The turbulence equations are nondimensionalized by the same reference quan- 
tities as the Navier-Stokes equations. The nondimensionalized variables used 
with the turbulence models are: 

k' k / k ref 

k = k* / a* 2 ref 
W = ^klef/plef^lef 

TD p* T *2 / * * 2 

■ k k re// kref “ re/ 

p _ p* r *2 / * *2 

— re// Pre/ U re/ 

T ij = T ij L ref/( k r ef a ref ) 

where, as in the previous sections, quantities denoted with * are dimensional. 
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3 Boundary Conditions 

This chapter discusses the boundary conditions available in Fun3D. Table 1 
lists the integers used to specify Fun3D boundary conditions with a short 
description. Each grid description subsection in section 4 indicates how these 
integers are specified. Details of the boundary condition implementation are 
provided by Carlson. [5] Details of symmetry boundary conditions are provided 
in section 3.1. Some boundary conditions have required or optionally specified 
parameters defined in the &boundary .conditions namelist, see section B.4.17 
for further boundary condition details. 
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BC 

Table 1: 

Description 

Fun3D boundary conditions. 
Notes 

-1 

Overlap 

overset grid boundary 

3000 

Tangency 

zero normal velocity, specified via fluxes 

4000* 

Viscous 

explicitly set the no-slip condition 

4110* 

Viscous 

implicitly set the no-slip condition 

5000 

Farfield 

Riemann invariants 

5026 

Extrapolate 

supersonic outflow, variables extrapolated from the interior 

5050 

Freestream 

external freestream, specified via fluxes 

5051* 

Back pressure 

specified static pressure (switches to extrapolation boundary 
condition in the presence of supersonic flow) 

5052* 

Mach outflow 

static pressure outflow boundary condition set via a specified 
subsonic Mach number (not for boundary layer ingestion) 

6021 

Symmetry plane 1 

symmetry enforced by replacing a;-momentum with zero ve- 
locity normal to arbitrary boundary plane. 

6022 

Symmetry plane 2 

symmetry enforced by replacing y-momentum with zero ve- 
locity normal to arbitrary boundary plane. 

6023 

Symmetry plane 3 

symmetry enforced by replacing z-momentum with zero ve- 
locity normal to arbitrary boundary plane. 

6100 

Periodicity 

discrete periodicity, limited to nominally 2D grids extruded 
across n planes in a third dimension 

6661 

A'-symmetry plane 

enforces symmetry for x Cartesian plane 

6662 

F-symmetry plane 

enforces symmetry for y Cartesian plane 

6663 

A-symmetry plane 

enforces symmetry for z Cartesian plane 

7011* 

Subsonic inflow 

Subsonic inflow ( Pt,bc = Ptotal, plenum fp static, freestreami 
Tt : bc = T t otal, plenum /T static, ,f reeS t r earn) nozzle Of tunnel 

plenum ( M in fiow < 1 ) 

7012* 

Subsonic outflow 

Subsonic Outflow ( Pb c = Pstatic, inlet /Pstatic, freestream for 

let flow (does not allow for reverse or supersonic flow at the 
outflow boundary face) 

7021* 

Reaction control jet plenum models the plenum of a reaction control system (RCS) jet 

7031* 

Mass flow out 

specification of massflow out of the control volume 

7036* 

Mass flow in 

specification of massflow in to the control volume 

7100* 

Fixed inflow 

fixed primitive variables in to control volume 

7101* 

Fixed inflow profile 

specified profile 

7103* 

Pulsed supersonic inflow 

pulsing supersonic flow 

7104* 

Ramped supersonic inflow 

ramping supersonic flow 

7105* 

Fixed outflow 

specified primitive outflow conditions 


* See &boundary_conditions namelist in section B.4.17 to specify auxiliary information and for 
further descriptions. 
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3.1 X-Symmetry, F-Symmetry, and Z-Symmetry 

The symmetry condition in FUN3D enforces discrete symmetry. That is, if 
the mesh were mirrored about the symmetry plane and run as a full-span 
simulation, the residuals (and therefore the outputs, such as lift, drag, etc.) 
will be identical. The FUN3D automated tests include a case were a mirrored 
grid is compared to the symmetry boundary condition. Discrete symmetry is 
also enforced where multiple symmetry condition intersect (i.e., a corner of 
Y -symmetry and Z-symmetry). 

Specifically, the condition enforces: 

• Any points on a symmetry plane are first “snapped” to the average 
coordinate for that plane. Many grid generators will have some small 
amount of “slop” in their y-coordinates for points on a y-symmetry plane; 
FUN3D immediately pops all of the points onto the exact same plane, 
at least to double precision. 

• The residual equation corresponding to the momentum normal to the 
symmetry plane is modified to reflect zero crossflow (i.e., pv = 0 on a 
y-symmetry plane). 

• The least squares system used to compute gradients for inviscid recon- 
struction to the cell faces is augmented to include symmetry contribu- 
tions across the symmetry plane (s). 

• All gradients of the velocity normal to the symmetry plane (v for a 
y-symmetry plane) in the source terms for the turbulence models are 
zeroed out. Gradients of the tangential velocities are zeroed out normal 
to the symmetry plane (du/dy, dw/dy). 

• No convective flux of turbulence normal to the symmetry plane. 

• Grid metrics (e.g., areas, normals) are forced to be symmetric at sym- 
metry planes. 
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4 Grids 


This chapter explains how to supply the proper hie formats to Fun 3D, but 
does not cover how to create a mesh. See section 1.3 for grid generation 
guidance. Fun 3D supports a direct reader for many grid formats. The format 
of the grid is specified in the &raw_grid namelist, section B.4.2. In addition to 
the directly read formats, translators are provided to convert additional grid 
formats into a format that can be read directly, see section 4.3. Fun 3D has the 
ability to apply rigid body rotations while reading the grid (see section B.4.4 
and section B.4.5) and mirror a grid about a symmetry plane (see section 4.5). 

4.1 File Endianness 

The ordering of bytes within a data item is known as “endianness.” If the 
endianness of a hie is different than the native endianness of the computer 
then a conversion must be performed. The endianness of each grid hie format 
is described in section 4.2. If your compiler supports it, Fun 3D will attempt 
to open binary hies with a open (converts..) keyword extension. Consult the 
documentation of the Fortran compiler you are using to determine if other 
methods are available. For example, with the Intel® Fortran compiler, the en- 
dianness of hie input and output can be controlled by setting the F_UFMTENDIAN 
environment variable to big or little. 

4.2 Supported Grid Formats 

Fun 3D natively supports the grid formats summarized in Table 2. 


Table 2: File extensions. 


Format 

Grid files 

BC File 

AFLR3 

.ugrid 

.mapbc 

FAST 

.fgrid 

.mapbc 

FieldView 

.fvgrid_fmt 

.mapbc 


.fvgrid_unf 

.mapbc 

FUN2D 

.faces 

.mapbc 

.mapbc 

VGRID 

.cogsg, .be 

FELISA 

.gri, .fro 

.bco 


* Same suffix, but GridTool format. 


The standard Fun 3D .mapbc hie format contains the boundary condition 
information for the grid. The hrst line is an integer corresponding to the num- 
ber of boundary groups contained in the grid hie. Each subsequent line in this 
hie contains two integers, the boundary face number and the Fun 3D bound- 
ary condition integer; these numbers may optionally be followed by a character 
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string that specifies a “family” name for the boundary. The family name is 
required if the patch_lumping option (section B.4.2) is invoked to combine 
patches into fewer patch families. Below is a sample .mapbc file illustrative for 
all grid formats except GridTool/VGRID, FELISA, and FUN2D, which are 
described later. 


13 


1 

6662 

box_ymin 

2 

5025 

box_zmax 

3 

5050 

box_xmin 

4 

5025 

box_ymax 

5 

5025 

box_zmin 

6 

5025 

box_xmax 

7 

3000 

wing_upper 

8 

3000 

wing_lower 

9 

3000 

wing_upper 

10 

3000 

wing_upper 

11 

3000 

wing_lower 

12 

3000 

wing_lower 

13 

3000 

wing_tip 

4.2.1 

AFLR3 Grids 


AFLR3, SolidMesh, Pointwise, and GridEx can all produce this format and 
Fun3D ships with translators that convert Plot3D and CGNS grids to AFLR3 
format. The format is documented online at http : / / simcenter.msstate.edu/ 
docs/ solidmesh/ugridf ormat.html 

AFLR3 grid file format types are indicated by file suffixes. The formatted 
(plain text) style has a .ugrid suffix while other types vary according to endi- 
anness (see section 4.1) and binary type as shown in Table 3. The boundary 


Table 3: AFLR3 non-ASCII grid suffixes. 

Type Little endian Big endian 

Fortran Stream, C Binary .lb8. ugrid .b8. ugrid 

Fortran Unformatted .lr8. ugrid .r8. ugrid 

conditions are specified via the standard FUN3D .mapbc format. 

4.2.2 FAST Grids 

The .fgrid file contains the complete grid stored in ASCII FAST format. 
The format is documented online at http://simcenter.msstate.edu/docs/ 
solidmesh/FASTf ormat.html The boundary conditions are specified via the 
standard FUN3D .mapbc format. 
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4.2.3 VGRID Grids 


The .cogsg file contains the grid nodes and tetrahedra stored in unformat- 
ted VGRID format. The VGRID cogsg files always have big endian byte 
order regardless of the computer used in grid generation. See section 4.1 for 
instructions on specifying file endianness. 

The .be file contains the boundary information for the grid, as well as a flag 
for each boundary face. For viscous grids with a symmetry plane, VGRID 
is known to produce boundary triangles in the .be file that are incompatible 
with the volume tetrahedra. Fun 3D provides a repair_vgridanesh utility to 
swap the edges of these inconsistent boundary triangles. If Fun 3D reports 
that there are boundary triangles without a matching volume tetrahedra, use 
this utility. 

VGRID has a different .mapbc boundary condition format. For each 
boundary flag used in the .be file, the .mapbc file contains the boundary type 
information. The VGRID boundary conditions are described at the website: 
http://tetruss.larc.nasa.gov/usm3d/bc.html. The Fun 3D boundary con- 
dition integers can also be used in place of the VGRID boundary condition 
integers. Internally, Fun 3D converts the VGRID boundary condition inte- 
gers to the Fun 3D boundary condition integers as indicated in Table 4. 

Table 4: Boundary type mapping between VGRID and Fun3D. 

VGRID FUN3D 

-1 -1 

0 5000 

1 6662 

2 5005 

3 5000 

4 4000 

5 3000 

44 4000 

55 3000 


4.2.4 FieldView Grids 

The ,fvgrid_fmt file contains the complete grid stored in ASCII FieldView 
FV-UNS format, and the ,fvgrid_unf file contains the complete grid stored 
in unformatted FieldView FV-UNS format. Supported FV-UNS file versions 
are 2.4, 2.5, and 3.0. With FV-UNS version 3.0, the support is only for the 
grid file in split grid and results format; the combined grid/results format 
is not supported. Fun 3D does not support the arbitrary polyhedron ele- 
ments of the FV-UNS 3.0 standard. For ASCII FV-UNS 3.0, the standard 
allows comment lines (line starting with !) anywhere in the file. Fun3D 
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only allows comments immediately after line 1. Only one grid section is al- 
lowed. The precision of the unformatted grid format should be specified by 
the f ieldview_coordinate_precision variable in the &raw_grid namelist, 
see section B.4.2. The boundary conditions are specified via the standard 
Fun 3D .mapbc format. 


4.2.5 FELISA Grids 

The .gri file contains the grid stored in formatted FELISA format. [6] The 
.fro file contains the surface mesh nodes and connectivities and associated 
boundary face tags for each surface triangle. This file can contain additional 
surface normal or tangent information (as output from GridEx or SURFACE 
mesh generation tools), but the additional data is not read by Fun 3D. The 
.bco file contains a flag for each boundary face. If original FELISA boundary 
condition flags (1, 2, or 3) are used, they are translated to the corresponding 
Fun 3D 4-digit boundary condition flag according to Table 5. Alternatively, 
Fun 3D 4-digit boundary condition flags can be assigned directly in this file. 


Table 5: Boundary type mapping between FELISA and Fun3D. 

FELISA FUN3D 

1 3000 

2 6662 

3 5000 


4.2.6 Fun 2D Grids 

The .faces file contains the complete grid stored in formatted Fun 2D format 
(triangles). Internally, Fun 3D will extrude the triangles into prisms in the 
^-direction and the 2D mode of Fun 3D is automatically enabled. Output 
from the flow solver will include this one-cell wide extruded mesh. 

Boundary conditions are contained in the Fun 2D grid file as integers 0- 
8. The mappings to Fun 3D boundary conditions are given in Table 6. If 
Fun 3D does not detect a .mapbc, it will write a .mapbc file that contains the 
default Table 6 mapping. If you wish to change the boundary conditions from 
the defaults based on the .faces file, simply edit them in this .mapbc file and 
rerun Fun 3D. The boundary conditions in the .mapbc file have precedence 
over the .faces boundary conditions. If you wish to revert to the boundary 
conditions in the .faces file after modifying the .mapbc, you can remove the 
.mapbc and rerun Fun3D. 
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Table 6: Boundary type mapping between Fun2D and Fun3D. 

FUN2D FUN3D 

0 3000 

1 4000 

2 5000 

3 -1 

4 4010 

5 4010 

6 5005 

7 7011 

8 7012 

4.3 Translation of Additional Grid Formats 

While Fun 3D supports the direct read of multiple formats, utilities are pro- 
vided to translate additional grid formats into a format that Fun 3D can read. 

4.3.1 PLOT3D Grids 

The utility plot3d_to_af lr3 converts a PLOT3D structured grid to an AFLR3- 
format hexahedral unstructured grid. The original structured grid must be 
3D multiblock http://www.grc.nasa.gov/WWW/wind/valid/plot3d.html (no 
iblanking) with the hie extension ,p3d for formatted ASCII or the the hie ex- 
tension .uf mt for Fortran unformatted. Only one-to-one connectivity is allowed 
with this option (no patching or overset). The grid should contain no singular 
(degenerate) lines or points. A neutral map hie with extension .nmf is also re- 
quired. This hie gives boundary conditions and connectivity information. The 
.nmf hie is described at http://geolab.larc.nasa.gov/Volume/Doc/nmf.htm. 

Note that the Type name in the .nmf hie must correspond with one of 
Fun3D’s BC types, plus it allows the Type one-to-one. If the Type is not 
recognized, you will get errors like: 

This may be an invalid BC index. 

An example .nmf hie is shown here for a simple single-zone airfoil C-grid 
(5 x 257 x 129) with six exterior boundary conditions and one one-to-one 
patch in the wake where the C-grid attaches to itself: 


Neutral 

Map File generated by the V2k software of 

NASA 

Langley's GE0LAB 

Block# IDIM 

JDIM KDIM 



i 

1 5 

257 129 



Type 

B1 FI SI El S2 E2 B2 F2 SI 

El 

S2 E2 Swap 
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1 tangency 1 
1 tangency' 

' f arf ield_extr ' 
' f arf ield_extr ' 
' one-to-one 1 
1 viscous_solid' 
' f arf ield_riem' 


1 3 1 257 1 129 

1 4 1 257 1 129 

1 5 1 129 1 5 

1 6 1 129 1 5 

111 5 1 41 1 1 1 5 257 217 false 

111 5 41 217 

12 1 5 1 257 


4.3.2 CGNS Grids 

Fun3D is distributed with a utility cgns_to_af lr3 that converts CGNS hies 
http://cgns.sourceforge.net/ to AFLR3 grids. This utility will only be 
built if Fun3D is conhgured with a CGNS library, see section A. 7. 13. Only 
the Unstructured type of CGNS hies are supported. The following CGNS 
mixed element types are supported: PENTA_6 (prisms), HEX_8 (hexes), TETRA_4 
(tets), and PYRAJ5 (pyramids). 

The CGNS hie must include Elementsvt nodes for all boundary faces (type 
QUAD_4 or TRI_3) to refer to the corresponding boundary elements. Otherwise, 
the utility cannot recognize what boundaries are present because it currently 
identifies boundaries via these 2D element types. The cgns_to_af lr3 utility 
requires that the BC elements be listed either as a range or a sequential list. 

It is also helpful to have separate element nodes for each boundary element 
of a given BC type. This way, it is easier to interpret the boundaries, i.e. , body 
versus symmetry versus farheld. Visualization tools, such as Tecplot™, can 
easily distinguish the various boundary condition groups as long as each group 
has its own node in the CGNS tree. Under BC_t, cgns_to_af lr3 reads these 
BC names, but ignores additional boundary data (e.g., BCDataSet, BCData). 


Table 7: Boundary type mapping between CGNS and Fun3D. 
CGNS FUN3D 


BCSymmetry Plane 
BCFarfield 
BCWallViscous 
BCWall 

BCWalllnviscid 

BCOutflow 

BCTunnelOutflow 

BCInflow 

BCTunnellnflow 


6661, 6662, or 6663 via prompt 

5000 

4000 

4000 

3000 

5026 

5026 

5000 

5000 


If the CGNS hie is missing BCs (no BC_t node), cgns_to_af lr3 still tries 
to construct the BCs based on the boundary face Element s_t information. If 
these boundary element nodes have a name listed in Table 7, a .mapbc hie 
will be written that contains the Fun3D boundary condition numbers. If the 
name is not recognized, you will see the message: 

WARNING: BC type ... in CGNS file not recognized. 
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in which case you will need to fix it by by editing the .mapbc hie manually. 
Always check the .mapbc hie after the utility has run, to make sure that the 
boundary conditions have all been interpreted and set correctly. If a trans- 
lation problem is observed, you should edit the .mapbc hie before running 
Fun3D. 

4.4 Implicit Lines 

The standard implicit solution relaxation scheme in Fun 3D is a point-implicit, 
which inverts the linearization of the residual at each node to compute an up- 
date to the solution. A line-implicit relaxation scheme can be used that inverts 
the linearization of a line of nodes simultaneously. Typically, lines are con- 
structed for the subset of nodes in the boundary layer to address the stiffness 
inherent in the Navier-Stokes equations on anisotropic grids. Therefore, the 
use of line- implicit relaxation may improve the convergence of viscous how sim- 
ulations. These lines are used in conjunction with the standard point-implicit 
relaxation scheme. Detailed descriptions of both line and point relaxation 
schemes are provided by Nielsen et al. [7] Currently, every viscous boundary 
node must have one and only one associated implicit line. Lines of nodes 
are specihed in a formatted hie with the suffix ,lines_fmt that contains the 
definitions of lines emanating from viscous boundary nodes as a list of node 
numbers. The format of the ,lines_fmt hie is 

[total number of lines] [total number of points in lines] 

[min points in a line] [max points in a line] 

[points in line 1] 

[first node of line 1] 

[last node of line 1] 

[points in line 2] 


4.5 Grid Mirroring 

A half computational domain with a symmetry plane can be mirrored to form 
a complete domain. This is a common use case for reflecting half of an aircraft 
configuration to form a full-span configuration to include the effects of side 
slip. Use the --mirror_x, --mirror_y, or --mirror_z command line options 
(section 5.2) to rehect the domain and remove the boundary patch located 
at x — 0, y — 0, or z — 0, respectively. When one or more of these mirror 
command line options are provided, Fun 3D will start execution on a grid that 
is mirrored internally during grid processing. The symmetry plane boundary 
face patch will be removed and each non-symmetry face patch will duplicated 
about the symmetry plane. These operations on boundary face patches will 
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alter the numbering of patches. Therefore, the boundary face indexes used 
to specify boundary conditions and co-visualization will be modified to track 
these changes. The user is required to update the indexes in these namelists 
appropriately. The hie [project_rootnarae] _mirror*.mapbc will be created 
in the current directory to aid this process. 

The internally mirrored grid will be discarded when execution is complete. 
So, provide the same mirror command line option to any restarted execu- 
tions. Alternatively, the --write_mesh [new_project] command line option 
is available to export the mirrored grid. Utilizing this exported grid would 
remove the need for the mirror command line option on subsequent runs. 
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5 Flow Solver, nodet 

This chapter covers what is required to run an initial flow solution, how to 
restart a flow solution, and how to specify what outputs the solver nodet 
produces. 

5.1 Flow Solver Execution 

The grid and flow conditions are specified in the file f un3d.nml; see section B.4 
for the file description. If you configured Fun 3D without MPI, the executable 
is named nodet. If you configured Fun 3D with MPI, the executable is named 
nodet_mpi. Configuration and installation is explained in detail in section A. 
The executable nodet can be invoked directly from the command line, 

nodet [fun3d options] 

but the MPI version nodet _mpi will need to be invoked within an MPI envi- 
ronment. The most common method is via 

[MPI run command] [MPI options] nodet_mpi [fun3d options] 

The details of the MPI run command and MPI options will depend on the MPI 
implementation. The MPI run command is commonly mpirun or mpiexec. 
The MPI options may contain the number of processors -np [n] , a machine 
file -machinef ile [file] , or no local -nolocal. If a queuing system is used 
(e.g., PBS) this command will need to be run inside an interactive job or a 
script. See your MPI documentation or system administrator to learn the 
details of your particular environment. 

If you have provided a grid with boundary conditions and fun3d.nml, you 
will then see the solver start to execute. If an unexpected termination happens 
during execution, especially during grid processing or the first iteration, you 
may need to set your shell limits to unlimited, 

$ ulimit unlimited # for bash 
$ unlimit # for c shell 

A detailed description of the output files is given below. 

5.2 Command Line Options 

These options are specified after the executable. The majority of the command 
line options are functionality under development and there is work underway to 
migrate command line options to namelists. Namelists are the preferred input 
method. Command line options should be avoided unless they are the only 
way to activate the functionality you require. These commands are always 
preceded by -- (double minus). More than one option may appear on the 
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command line (each option proceeded by a -- ). You can see a listing of the 
available command line options in any of the codes in the Fun 3D suite by 
using the command line option --help after the executable name, 

. /nodet_mpi — help 

The options are then listed in alphabetical order, along with a short de- 
scription and a list of any auxiliary parameters that might be needed, and 
then the code execution stops. Specific examples of the use of command line 
options are found throughout this, and later, chapters. 

5.3 Output Files 

These are the output hies produced by the how solver, nodet. 

[project jrootname] .f low This hie contains the binary restart infor- 
mation and is read by the solver for restart computations. See the restart _read 
namelist variable in section B.4.13 to control restart behavior. 

[project jrootname] _hist.dat This hie contains the convergence his- 
tory for the RMS residual, lift, drag, moments, and CPU time, as well as the 
individual pressure and viscous components of each force and moment. The 
hie is in Tecplot™ format. See section B.4.22 for an improved method to track 
forces and moments. 

[pro j ect jrootname] _subhist.dat For time accurate computations only. 
This hie contains the sub-iteration convergence history for the RMS residuals, 
together with force and moment histories. Force and moment histories rehect 
the combined viscous and pressure components. The hie is in Tecplot™ format 
and is overwritten each time the code is run. 

[proj ect jrootname] .forces This hie contains a breakdown of all the 
forces and moments acting on each individual boundary group. The totals for 
the entire configuration are listed at the bottom. See section B.4.22 for an 
improved method to track forces and moments. 

5.3.1 Flow Visualization 

There are four basic categories of output: boundary data, sampling data (on 
entities such as planes, boxes and spheres), volumetric data, and slice data 
controlled by the namelists in Table 8. 

Each namelist has a corresponding frequency variable, A positive frequency 
will cause the output to be generated every frequency time step/iteration. A 
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Tabic 8: Solver output types. 

Type Namelist 


domain boundaries 
domain volume 
boundary slices 
various geometries 

point 


feboundary .output _var i abl e s 
fevolume.output .variables 
&slice_data 

&sampling_parameters and 
&sampling_output .variables 
&sampling_parameters and 
&sampling_output .variables 


section B.4.26 
section B.4.25 
section B.4.29 
section B.4.28 and 
section B.4.27 
section B.4.28 and 
section B.4.27 


negative frequency will cause output to be written only at the end of a run. A 
zero frequency (the default) with produce no output. See the corresponding 
namelist descriptions for details. 

5.3.2 Flow Visualization Output From Existing Solution 

If a Fun 3D flow solution already exists, visualization hies can be produced 
by setting steps = 0 or steps = 1 in the &code_run_control namelist (sec- 
tion B.4.13) and setting the restart_read variable to something other than 
’off’. One iteration is required to compute gradient quantities (i.e., skin 
friction). This will allow generation of visualization output without having to 
repeat the entire calculation. 
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6 Adjoint Solver, dual 

This section describes how to execute the adjoint solver, dual, directly. Typ- 
ically, dual is executed by scripts that manage the multiple steps required 
for design optimization (section 9) or grid adaptation (section 8). However, 
it may be necessary to run DUAL directly to diagnose problems or gain expe- 
rience during setup including determining input parameters and termination 
strategies. Fun3D is configured to compile dual by default. While the ad- 
joint method is available for most commonly used Fun3D capabilities, only a 
subset of Fun3D’s full capabilities are implemented in the adjoint solver. 

6.1 Convergence of the Linear Adjoint Equations 

The adjoint solution is dependent on the primal flow solution (and the con- 
vergence of the primal flow equations). While the primal solution may have 
converged enough to give acceptable force and moment results, the flow resid- 
uals might still be large, which can cause the adjoint solution scheme to di- 
verge. This divergence issue is most common in turbulent simulations. A 
divergent adjoint scheme can be improved in some circumstances with the 
— outer_loop_krylov command line option. It is critical to run the flow 
solver and the adjoint solver with the same governing equations and bound- 
ary conditions. 

The scaling of the adjoint residuals is different from the flow residuals 
and is dependent on the choice of the adjoint cost functions. The number of 
iterations steps and the residual tolerance stoppingvtolerance will need to 
be adjusted, see section B.4.13. The sensitivities should converge at the same 
rate as your functions (i.e., lift), but an adjoint with some algebraic error may 
still provide reasonable sensitivities for design and grid adaptation. 

6.2 Required Directory Hierarchy and Executing dual 

The executable dual can be invoked directly from the command line, 
dual [fun3d options] 

but the MPI version dualunpi will need to be invoked within an MPI envi- 
ronment. The most common method is via 

[MPI run command] [MPI options] dual_mpi [fun3d options] 

Any [fun3d options] provided to NODET that control the flow solver residual 
will also be required for the adjoint solver for a consistent adjoint solution and 
solution scheme. See the flow solver execution instructions for more details, 
section 5.1. 
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DUAL expects the cost function description ../rubber. data to be in the 
parent directory of the directory from which it is invoked. The input and 
flow restart hies are shared with NODET in the directory ../Flow/. The how 
solver must be run to completion, to provide a how restart hie, before dual 
is invoked. See Table 9 for the required hies and locations. 


Table 9: Adjoint solver DUAL directory hierarchy. 

Relative Path Description 

../Flow/ [pro ject_rootname] .flow Primal how solution (restart) 

../Flow/fun3d.nml Main input namelist hie 

../rubber. data Description of the adjoint cost function 


6.3 rubber. data 

The minimum required rubber. data for running the adjoint (and grid adap- 
tation) can be written with the command 

f3d function [cost function name] 

Available cost function names are discussed in section 9.1 and listed in Ta- 
ble 10. See section 9.6.2 for complete details on this hie format including the 
information required for design. The rubber. data reader requires the exact 
number of header lines. Be very careful when editing this hie. 

6.4 Output Files 

The adjoint solver will export visualization hies in the same manner as the 
how solver when requested, see section 5.3.1. 

[project jrootname] .adjoint This hie contains the binary restart in- 
formation and is read by the and adjoint solver for restart computations. 

[project _rootname] _hist.tec This hie contains the convergence his- 
tory for the RMS residual of the adjoint equations and CPU time. The hie is 
in the same Tecplot™ format as the how solver produces. History information 
is truncated when the adjoint solver is restarted. 


41 


7 Grid Motion 


Fun 3D has an extensive capability for grid motion. Grid motion may be 
rigid, where points in the grid move in unison, or grid motion may result from 
elastic deformation of the grid to follow the motion of one or more boundaries 
in the domain. To accommodate both types of grid motion, a distinction is 
made between ‘body motion’ and ‘grid motion’. The user begins by defining 
one or more bodies (a body being a collection of one or more boundary patches 
in the grid), and specifies how that body is to move. This section describes 
how to specify the motion of each body as rigid motion, elastic motion, or 
a combination of rigid and elastic motions. The motion and deformation of 
volume grid surrounding the bodies is controlled through the concept of mesh 
movement (see section 7.2). 

Motion requires the introduction of reference frames. Fun 3D solves the 
flow equations in an inertial reference frame (one exception to this, section B.4.8, 
can not be used with grid motion). Each moving body has its own reference 
frame; the body frame is taken to coincide with the inertial reference frame 
at t — 0. In addition to the inertial and body reference frames that are au- 
tomatically bookkept when grid motion is activated, the user may define an 
‘observer frame’ for visualization output. Typically, the ‘observer frame’ is 
either the inertial frame (default) or one of the moving body frames. There is 
the provision for the observer frame to move independently, if required. 

Fun 3D allows for hierarchical (parent /child) body motions in which the 
motion of one body follows the motion of another body. The top level of these 
hierarchical motions is the inertial frame, and the default parent frame of any 
moving body is taken as the inertial frame (i.e. , by default the motion of a 
body is assume to be relative to the inertial frame). 

For all but a few specialized capabilities discussed below (see section 7.5), 
grid motion requires that Fun 3D be executed in ‘time-accurate’ mode (see 
section B.4.14). To activate grid motion, the input variable moving_grid = 
.true, in the &global namelist is required. Finally, an additional input hie, 
mo ving_body. input, is needed to establish the details of the motion (see sec- 
tion B.5). 

Any grid motion that the user specifies leaves the original grid file unaltered. 
Grid motion always starts from the input grid set in the &raw_grid namelist 
(see section B.4.2). The Fun 3D restart hie contains enough information so 
that motion can be continued seamlessly through restarts. If the user would 
like to obtain a new grid hie with the grid in its position at the end of the 
execution, use the command-line option --write unesh [new_pro j ect] , where 
[new.project] is the project name of the new grid hie. Note that regardless 
of the grid format of the original mesh, the new mesh format will be in AFLR 
stream format (b8.ugrid). 

The distance function needed for any turbulence model is computed once 
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by default, based on the input grid. If the entire grid is moved rigidly, the 
distance function remains unchanged with motion. However, for deforming 
grids and (to a lesser extent) rigid overset grids, the distance from a point 
to the nearest surface may change to some extent as the grid is moved from 
the initial state. For deforming meshes, the grid points nearest to the sur- 
face behave as a nearly rigid grid, so the effect on the distance function is 
minimal. Currently, it is up to the user to decide if the extra cost of re- 
computing the distance function is justified. As defined in section B.4.24, 
setting recompute_turb_dist = .true, will force the distance function to be 
recomputed every turb_dist_update_f req time steps when grid motion is ac- 
complished by deformation, or if overset grids are used. The distance function 
is never recomputed for rigid meshes that do not require overset connectiv- 
ity. These same distance function considerations also apply to the specialized 
capabilities discussed in section 7.5. 

7.1 Overview of movingJbody. input 

Moving-grid cases require the movingJbody. input input hie. Complete details 
are provided in section B.5 and an overview is proved here. Within this hie, ba- 
sic information required for all moving-grid cases is accomplished through the 
&body_def initions namelist (see section B.5.1). Depending on the the type of 
‘motion driver’ selected (i.e. how the body is to be moved), additional namelist 
input is usually required. The &f orcedunotion namelist (See section B.5. 2) 
allows the user to specify constant translation and/or rotational motion of 
a body. The &motion_f rom_f ile namelist (see section B.5. 4) specihes body 
motion by providing a time sequence of 4 x 4 transform matrices, and is the 
most general means of specifying rigid-body motion. The &observer_motion 
namelist (see section B.5. 3) allows the user to specify motion of an ‘observer’ 
reference frame. Visualization (see section 5.3.1) is in the ‘observer’ frame. 

7.2 Choosing the Type of Mesh Movement 

The user must choose a means to move the mesh that will accommodate 
the prescribed or calculated body motion. As described in section B.5.1, 
the choices are meshunovement = ‘ rigid’ , meshunovement = ‘ deform’ , or a 
combination of the two (e.g. meshunovement = ‘ rigid+def orm’ . Whenever 
possible, the most robust and fastest executing option is ‘rigid’, since rigid 
motion is quickly and efficiently applied via a 4 x 4 transform matrix (see 
section 7.3) and is guaranteed to maintain positive cell volumes as the mesh 
is moved. Mesh deformation, on the other hand, increases the computational 
time as it requires the solution of an additional system of partial differential 
equations (linear elasticity). Furthermore, there is no guarantee of positive cell 
volumes after deformation. Fun 3D will automatically try to fix negative vol- 
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umes during deformation, but this is rarely successful. Execution terminates 
when negative cell volumes are encountered and cannot be remedied. 

Elastic body deformations of the preclude purely rigid grid motion (i.e., the 
body itself undergoing deformation, as occurs for aeroelastic bodies). However, 
some cases can benefit from the combination of rigid and deforming mesh mo- 
tion. This can allows large-scale motion to be described as rigid motion and 
reduces the magnitude of the clastic deformation to smaller-scale motions. 
Reducing the magnitude of body elastic motions can reduce the cost of com- 
puting the clastic deformation of the adjacent volume grid. Smaller elastic 
deformations also increase the robustness by reducing the likelihood of gener- 
ating negative volumes. An example of combined rigid and clastic deformation 
is a rotor blade of a rotorcraft simulation, where rigid motion is used to rotate 
the blades around the shaft axis and elastic deformation is used to deform the 
the blade under aerodynamic loading. 


7.3 4x4 Transform Matrices 

All rigid motions (body and/or grid) within Fun 3D are accomplished via ap- 
plication of 4 x 4 matrices to describe affine transformations. [8] These trans- 
forms map a body/grid from the position at t — 0 to the current position at 
t = T. The inverse of these transforms are used to map a body/grid from 
its current position back to its position at t — 0. Although the user usually 
does not need to know the details of these transform matrices to use the grid 
motion capability in Fun 3D, they are described below for reference. 

The 4x4 transform matrices contain both translation and orthonormal 
rotation components. Given a point at an initial position (x, y , z) T , application 
of the transform matrix moves the point to its new position (x',y\z') T 


x' 


Rll R\2 Rl 3 T x 


X 

y' 
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y 
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0 0 0 1 


1 


where the 3x3 submatrix entries in the upper left define an orthonormal 
rotation about the origin, (0, 0, 0) T , and the last column defines a translation. 
The last row is always set as (0, 0, 0, 1) T . Application of the inverse of this 
transform matrix moves the point back to the initial position. 

Two often-encountered transforms are a pure translation from the origin 
to a point (x 0 , y 0 , z 0 ) T and a pure rotation 0 in the direction n (unit vector) 
about the origin 
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[To] 


1 0 0 x 0 
0 1 0 yo 

0 0 1 Zq 

0001 


[Ro] = 

where s9 = sin(d) and c9 = cos(d). The right-hand rule in the direction of 
n defines the sense of 9. Other forms of the 3x3 rotation submatrix may 
arise depending on how the motion is specified (e.g., chained rotations such as 
Euler angles). Note that [To] -1 is simply [T 0 ] with (To, Vo, zq) t replaced by 
(~x 0 , — |/o, -Z 0 ) T , and maps (x 0 , y 0 , z 0 ) T to the origin. 

An extremely useful feature of the transform matrix approach is that multi- 
ple transformations telescope via matrix multiplication. Thus, rotation about 
a point (T 0 , Vo, zq) t , by an angle 9 , in the direction n is effected by first trans- 
lating to the origin, performing the rotation, and then translating back to 
(To, l/o, A)) T , which is accomplished via three matrix multiplications to give 
the complete transform matrix [T] 

[T] = [T„][R 0 ][T 0 ]-‘ 

The telescoping property of the transform matrices is also useful for track- 
ing motions of one body relative to another. For example, a wing may be 
translating up and down, while at the same time, a flap may be pitching 
about a hinge line fixed on the wing, ft is natural to describe the pitching 
motion of the flap in its own coordinate system, which at t=0 is the same as 
the wing coordinate system. If the transform matrix describing the plunging 
of the wing relative to its initial position in an inertial reference frame is given 
by [T] w ; ng , and the transform matrix of the pitching motion of the flap relative 
to a hinge line defined in the flap coordinate system is given by [T]fl ap , then 
the position of the flap, relative to the inertial frame, may by computed using 
the composite transform 


(1 — c9)n x 2 + c9 
(1 — c9)n x n y + n z s9 
(1 — c9)n x n z — n y s9 

0 


(1 — c9)n x n y — n z s9 
(1 — c9)n y 2 + c9 
(1 — c9)n y n z + n x s9 

0 


(1 — c9)n x n z + n y s9 0 
(1 — c9)n v n z — n x s9 0 
(1 - c9)n z 2 + c9 0 

0 1 


[T] — [T] w ing [T] fl a p 

The order of matrix multiplication is important: post multiplication of the par- 
ent transform takes coordinates from the child system into the parent system, 
which is then moved relative to the inertial frame according to the parent 
transform. The example above is for a simple, one-generation, parent-child 
composite motion, but the concept may be extended to any number of gener- 
ations. 
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7.4 Verifying Grid Motion Inputs 


When setting up a moving-grid case, it is usually a good practice to verify that 
the desired grid motion will be performed before an attempt is made with a 
large and potentially expensive time-dependent flow solution. There are two 
options that may be used to check that the motion setup is correct; both must 
be used in conjunction with boundary output to be useful (see section 5.3.1). 
Both options bypass the flow-solution but not the grid-motion mechanics. Be- 
cause these options decouple the flow solution and the grid motion, they are 
generally restricted to cases in which the motion is prescribed by the user. 
If the motion results from aerodynamic loading, such six degrees of freedom 
motion or as a result of aeroelastic deformation, there is no complete check 
but to run the coupled simulation. However, it may be possible to prescribe 
a motion that is similar to the expected motion so that body definitions and 
time step sizes may be verified prior to the coupled solution. 

The first option is enabled by setting body_motion_only = .true, in the 
&global namelist. As the name of the option implies, only the user-defined 
bodies are moved, not the entire mesh. This is the quickest check, especially 
for deforming meshes, since the elasticity equations are not solved. Volume 
and surface elements adjacent to the moving bodies will likely become inverted 
during this test. So, expect to see inverted elements in visualization of output 
grids on symmetry boundaries, farfield boundaries, sampling planes, etc. 

The second option is more discriminating for deforming grids, and is en- 
abled by setting grid_motion_only = .true, in the feglobal namelist. This 
option runs through the entire grid-motion mechanics, including solution of 
the linear elasticity equations for deforming grids. This will significantly in- 
crease the computational time for this check compared to bodyunotiomonly 
= .true.. For deforming meshes, this option will indicate whether or not the 
mesh will survive the prescribed motion without negative volumes. All visual- 
ization options can be used with this option to observe the surface and volume 
grid deformation. 

Because body_motion_only = .true, option is fairly quick even for deform- 
ing meshes, the recommended approach for deforming meshes is to do start 
with body_motion_only = .true, to verify that the body moves as desired. 
After the basic motion is verified, the grid_motion_only = .true, can be ex- 
ercised, to ensure the deformation will be successful as the body executes its 
motion. Both body and grid motion are fast for rigid meshes. 

For periodic motions it is strongly recommended to verify that the bodies 
return to their initial position after the expected number of time steps. Failure 
to return to the initial position at the expected time likely indicates an error 
in the input time step or the nondimensional frequency. Insufficient numerical 
precision of the input values of these quantities can prevent a return to the 
initial position after one period. 
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7.5 Static Grid Manipulations 

Several options available to move or deform the grid during pre-processing 
are not considered ‘moving grid’ options. Therefore, these static grid manip- 
ulations do not require the code to be run in a time-accurate manner, the 
moving.body. input hie, or moving.grid = .true, in the &global namelist. 
These static manipulations result in a one time movement of the mesh at 
the start of the code execution. As with moving grids, the original grid 
hie specihed in the &raw_grid namelist (see section B.4.2) remains unal- 
tered. The body .mot ion.only or grid_motion_only options do not apply to 
these static grid manipulations. As for time-accurate moving grids, the rigid- 
grid option (fegrid.transf orm) is preferred over the deforming grid option 
(febody .transform) whenever possible because it is less expensive and more 
robust. 

7.5.1 Grid Transform 

This static grid manipulation is governed by the fegrid.transf orm namelist in 
the fun3d.nml hie (see section B.4.4). It allows the entire grid to be rotated, 
translated, or scaled with a few simple inputs. A more general manipulation 
of the grid may be obtained through the input of a 4 x 4 transform matrix. 

7.5.2 Body Transform 

This static grid manipulation is governed by the &body .transform namelist 
in the fun3d.nml hie (see section B.4.5). It allows user-defined bodies to 
be rotated or translated (but not scaled). An example would be to make 
a small change to the angle of a hap, while leaving the orientation of the 
wing unchanged. The namelist allows for one or more bodies to be defined 
as collections of one or more boundaries in the grid, where each body may 
be manipulated independently of the others. As with the fegrid.transf orm 
option, a 4 x 4 transform matrix may be input if the simple rotation and 
translation options provided by the namelist input are insufficient to describe 
the transform. When this option is used, the specihed bodies will be moved 
according to the input, and the mesh will be deformed to accommodate the 
new body positions. 
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8 Grid Adaptation 


Fun 3D implements metric-based adaptation, where grid adaptation is sepa- 
rated into two tasks. The first step is to construct a metric that describes the 
desired size and anisotropy of the adapted grid elements. The second step is 
to produce an adapted grid that is based on this metric. 

Feature-based adaptation constructs the metric based on properties of the 
flow solution. Adjoint-based adaptation constructs the metric from the flow 
and adjoint solutions to reduce estimated errors in a specified output func- 
tion. The namelist feadapt unetric_construction (section B.4.32) specifies 
the metric construction method. The related namelist description and docu- 
mentation provides the mathematical formulation of the metric. 

Fun 3D supports a number of grid adaptation libraries. The namelist 
feadaptunechanics (section B.4.33) specifies the grid adaptation library and 
its options. The REFINE grid adaptation library is distributed and installed 
with Fun 3D by default. 

8.1 Geometry Specification and Grid Freezing for re- 
fine 

When adapting a grid with REFINE version one ( adapt _libr ary = ’refine/ 
one’ in &adapt_mechanics), all boundary faces must be specified as frozen 
or a geometry definition mush be provided via FAUXGeom. Use the default 
patch_lumping= ’ none ’ in the &raw_grid namelist, as lumping will change 
boundary patch indexes making it more difficult to specify geometry. 

8.1.1 No geometry, where the surface nodes are frozen. 

REFINE version one cannot preserve the high aspect ratio structures within 
viscous layers, and so viscous layers must be frozen for a specified distance 
away from the surface to maintain grid quality. This is invoked with the 
adapt_freezebl command within the &adaptation_mechanics namelist, see 
section B.4.33 for more details and for guidance in specifying this distance. 

Additionally, specific surfaces that do not have a viscous boundary condi- 
tion can be frozen by listing the surface numbers (one per line) in a hie named 
[pro j ect_rootname] .freeze. For example, [pro j ect_rootname] .freeze that 
contains 

5 

7 

will freeze points on boundary patches 5 and 7. This is also useful for boundary 
surfaces that do not have an analytical definition handled by FAUXGeom. 
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8.1.2 FAUXGeom for Planar Boundaries 


For viscous problems, where the mesh on the complex geometry of the body is 
frozen, FAUXGeom can be used to provide an analytical definition of planar 
symmetry, farheld, and propulsion boundary surfaces. This allows adapta- 
tion to occur on these planar surfaces of the mesh, even when the boundary 
layer mesh is frozen. This is a particularly important capability for symmetry 
planes. At present, FAUXGeom can only handle planar surfaces. 

FAUXGeom reads the hie faux_input. Here is an example hie: 


4 

5 xplane -5.0 
3 yplane -1.0 
1 zplane 1.0 
16 general_plane 2.0 
0.707 0.707 0.0 


The hrst line is how many faux surfaces are being defined. The subsequent 
lines have a face number, type of face, and a distance associated with the 
particular geometry. In this example, the hrst faux face defined corresponds 
to surface 5 in the mesh and is an x = —5.0 constant plane. Faux faces are 
similarly defined for the z and y planes of surfaces 3 and 1. Surface 16 is 
a plane perpendicular to a (0.707,0.707,0.0) normal that is located 2.0 away 
from the origin in the direction of the normal; the plane passes through the 
point (1.414,1.414,0.0). 


8.2 Performing Feature-Based Adaptation 

The feadapt unetric.construction variable adapt_f eature_scalar_f orm de- 
fines the operator that is applied to the adapt_f eature_scalar_key to com- 
pute an adaptation intensity. This intensity is raised to the adapt .exponent 
power to produce a scaling of an isotropic element size estimate on the cur- 
rent grid. The anisotropy of the metric is introduced by the Hessian of the 
adapt _hessian_key variable. See section B.4.32 for complete details and 
mathematical description. 

Set restart_read=’ on J in section B.4.13 to read the how solution. Run 
NODET with the --adapt command line option in the directory with the how 
restart. The result will be a new grid and interpolated solution hie with 
the adapt.project project name. After adaptation, the how solver can now 
be restarted with this new grid and interpolated solution by changing the 
pro j ect_rootnarae. 
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8.3 Performing Adjoint-Based Adaptation 

Adjoint-based adaptation requires that a flow solution be calculated in the 
Flow directory and an adjoint solution be calculated in the Adjoint directory. 
See section 6 for more information on obtaining an adjoint solution. The 
adjoint solution is based on the functional defined in rubber. data and this is 
the same functional targeted for grid adaptation. 

Adaptation is performed by executing DUAL with the command line op- 
tions — rad — adapt. The adjoint solver reads the fun3d.nral in the ../Flow 
directory), so this is the place to specify feadapt unetric_construction and 
&adapt_mechanics options. The freeze and FAUXGeom files are read in the 
current directory, Adjoint. 

The result will be a new grid and interpolated solution restart file in the 
../Flow directory and an interpolated adjoint restart in the Adjoint directory. 
The project name of these new files is adapt ^project. 


8.4 Scripting Grid Adaptation 

The Fun 3D installation includes the f3d Ruby script. To find the other 
components of the Fun 3D suite, the f3d script expects to be in the bin 
directory of the Fun 3D installation. Don’t copy or link f3d from the bin 
directory. The input file case.specif ics is described in section 8.4.1. 

Execute the f 3d script in a directory that contains all of the the input files 
(e.g., grid, fun3d.nral, case_specif ics). The script will create the required 
Flow and Adjoint directories to run the case. It has the following commands, 


usage: f3d <command> 
<command> description 


start 

view 

watch 

shutdown 

clean 


Start adaptation 

Echo a single snapshot of stdout 
Watch the result of view 

Kill all running fun3d and ruby processes 
Remove output and sub directories 


function [name] write rubber. data with cost function [name] 


The command start begins adaptation by launching a background job. The 
commands view and watch allow the adaptation progress to be monitored. 
(Use Ctrl-C to escape the watch command.) The shutdown command kills 
all Ruby (f3d) and Fun 3D jobs. The clean command removes the Flow and 
Adjoint subdirectories and the output log file. The function command with 
argument creates the rubber. data file to define the adjoint cost function. 
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8.4.1 Input File case specif ics for f3d Script 

The f3d script has one input file, named case.specif ics. Here is an example 

root_project ' ' 
number_of _processors 2 
mpirun_command 'mpiexec' 
f irst_iteration 1 
last_iteration 10 

# Any text after a number sign is a comment. 

where the defaults are listed. Adaptation will be performed from the first grid 
adaptation iteration 1 to the last grid adaptation iteration 10. The string in 
quotes next to root.project is the project root name. A two digit iteration 
number will be appended to it. The project name for the first adaptation will 
be [root.project] 01 and the last will be [root_project] 10. All the files 
required to run NODET and DUAL should be provided in the current directory 
and the grid filename should include the root project name and iteration num- 
ber, [root.project] 01. Flow and Adjoint subdirectories are created by the 
script during execution, and the input files are placed in their correct location 
by the script. 

Command line options can be passed to the codes via, 

all_cl 1 1 
f lo_cl ' ' 
adj_cl ' ' 
rad_cl ' ' 

where all_cl is provided to all codes, flo_cl is provided to nodet, adj_cl 
is provided to DUAL during the adjoint solve, and rad_cl is provided to DUAL 
during error estimation and adaptation. For example, the line 

adj_cl ' — outer_loop_krylov ' 

turns on Krylov projection wrapping to stabilize the adjoint solve. Note that 
the command line arguments should be surrounded by spaces to avoid collisions 
during assembly. 

The main input file fun3d.nml provided in the current directory can be 
modified by the following commands 

all_nl [' variable '] = value 
f lo_nl [' variable '] = value 
adj_nl [' variable '] = value 
rad_nl [' variable '] = value 

where all_nl changes fun3d.nml for all codes, flo_nl for NODET, adj_nl for 
DUAL during the adjoint solve, and rad_nl for DUAL during error estimation 
and adaptation. An example is 
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adj _nl [ ' steps ' ] =500 

adj_nl [ ' stopping_tolerance ' ] =1 . Oe-12 


where the termination criteria of the adjoint solver can be specified separately 
than the flow solver. 

The case.specif ics is actually executable Ruby code. This allows values 
to be computed or conditionally executed, but also requires nested quotes for 
character strings, e.g., 

rad_nl [ ' adapt_complexity ' ] = 5000*iteration 
number_of _processors 128 if (iteration>5) 
all_nl [ ' f lux_construction ' ] = "'vanleer'" 


8.5 Examining Convergence of the Adaptive Grid Pro- 
cess 

For feature-based adaptation, there are no tools available to study the conver- 
gence of the adaptive grid process, only the solution, grid size, and functional 
output of the flow solver are available. The practitioner is left to examine the 
results and exercise engineering judgment. 

For output-based adaptation, the items available for feature-based adapta- 
tion are augmented with a remaining error estimate and an error corrected 
functional for adapt.error.estimation = ’embed’. While the error cor- 
rected functional is printed to standard output for adapt _error_estimat ion 
= ’ single’ , it should not be used for monitoring, because it is correcting the 
algebraic error of the reconstructed solution (not the discretization error as in 
the embedded grid method). 

The system grep command can be used to extract this information. For 
example the adapted grid size is 

grep nnodesg Adjoint/*_rad_out 

where the last argument is the hie where standard output is stored. The 
remaining error estimate is extracted with 

grep remaining_error Adjoint/*_rad_out 

and both the linear and high order corrected functional is extracted with 

grep function_corrected Adjoint/*_rad_out 

where the linear is listed before the higher order. The higher order corrected 
functional is preferred to examine convergence, and the linear corrected func- 
tion is provided to hag any problems with interpolation. Again, these error 
corrected functionals are not valid for adapt_err .estimation = ’single’. 
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8.6 Adaptive 2D Simulations 

There are a number of considerations for performing grid adaptation of 2D ge- 
ometries. A 3D grid should be used with one layer of spanwise prism elements 
between symmetry planes at y = 0 and y — 1. The adjoint solver lacks a 
2D-specific mode, so set twodunode = .false, in the feraw.grid namelist. To 
properly construct the metric from the 3D grid and solution, set adapt _twod = 
.true, in the &adapt_metric_construction namelist. An adaptation library 
that supports 2D should be selected from adapt .library in &adapt .mechanics. 
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9 Design Optimization 


The Fun3D design framework uses a gradient-based optimization procedure. 
One potential approach to obtaining the required sensitivity derivatives is 
a conventional forward mode of differentiation, such as finite-differencing, 
complex-variable formulations, operator overloading, or direct differentiation. 
Since the cost of these techniques scales directly with the number of input pa- 
rameters, these methods are most efficient for problems where the number of 
outputs is considerably larger than the number of inputs. For such problems, 
Fun3D provides a complex variable formulation as described in section 9.14. 
However, for most aerodynamic design problems, the converse is true; the 
number of design variables is typically much larger than the number of objec- 
tive functions and/or constraints. In this context, an adjoint, or reverse mode 
of differentiation is preferred. 

Fun 3D provides a discrete adjoint capability to efficiently determine the 
sensitivities required by a gradient-based design procedure. The adjoint ap- 
proach enables the user to compute sensitivity derivatives of an output function 
with respect to an unlimited number of design variables at a cost equivalent 
to a single additional flow solution. For a general review of sensitivity analysis 
techniques, see [9] and [10]. 

The adjoint approach used in Fun3D relies on discrete linearizations of the 
relevant components of the flow solver. Most of Fun3D’s compressible perfect 
gas and incompressible capabilities are accounted for within the adjoint-based 
framework. Discretely consistent sensitivities have been demonstrated for both 
steady and unsteady inviscid, laminar, and turbulent flows based on the one- 
equation model of Spalart and Allmaras. Grid topologies may contain any 
combination of element types and may also contain overset grid discretizations. 
Grids may be static, non-inertial, or may contain any combination of static, 
rigidly-moving, or deforming overset component grids. Both compressible and 
incompressible formulations are available. The most commonly-used boundary 
conditions are implemented in the adjoint framework, and a broad range of ob- 
jective/constraint functions is also available. However, the user is encouraged 
to review the latest release notes or contact Fun3D-Support@lists .nasa.gov 
to determine if a specific analysis capability is currently supported by the ad- 
joint implementation. For a detailed overview of the adjoint-based procedure 
used in Fun3D and examples of its use for design optimization, see [11] and 
the references contained therein. 

Users are encouraged to gain extensive experience using Fun 3D for anal- 
ysis purposes before attempting design optimization. This experience will aid 
in properly setting up optimization cases, understanding the steps involved, 
and interpreting the results. 

The adjoint-based algorithms are very efficient, but a typical optimization 
will still require the equivalent of 0 ( 20 ) typical analyses. Therefore, secur- 
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ing sufficient computational resources is critical to performing realistic high- 
fidelity design. It should also be noted that the various optimization packages 
supported by Fun 3D may behave very differently for a given design problem; 
moreover, the optimal algorithm is generally problem-dependent. 

At this time, the documentation provided here is aimed at design opti- 
mization of steady flows. The extension to simulations involving unsteady 
flows is available for general use (e.g., see [12]), but is not currently covered 
here. Please contact Fun3D-Support@lists.nasa.gov if interested in using 
this capability. 

9.1 Objective/Constraint Functions 

To perform a gradient-based optimization, the user must specify at least one 
objective function to quantify the merit of the configuration. In the Fun 3D 
design infrastructure, such objective functions may take a very general form as 
described here. Note that all of the supported optimization packages always 
seek to minimize the chosen objective function. Care should be taken to pose 
the objective function accordingly. Multiple outputs may be accounted for in 
a variety of ways. Constraints may be included implicitly within the objective 
function(s) as penalty terms. Explicit constraint functions may also be posed, 
as either equality or inequality constraints. 

Note that the primary limitation in posing the problem statement is the 
general ability of the chosen optimization package to handle the design prob- 
lem posed by the user. For example, the PORT optimization software does 
not support the use of explicit constraints. KSOPT is the only supported op- 
timization package that supports the use of more than one objective function; 
however, Fun 3D offers several approaches to scalarize multiple objectives for 
other packages. Multi-point design is also supported in several forms. See 
section 9.9 and section 9.10 for specific details on these capabilities. 

The Fun 3D flow and adjoint solvers do not distinguish between objective 
functions and constraints. The solvers themselves merely provide function 
values and their sensitivities for use during the optimization procedure. The 
actual optimization packages are the only components in the design framework 
that make a distinction between objective functions and constraint functions. 

9.1.1 Terminology 

It is useful to establish some basic terminology when composing the design 
problem statement. Within the Fun 3D design infrastructure, the user speci- 
fies one or more component functions based on typical solver outputs. These 
component functions are then combined to form a single composite function. 
Multiple component functions may be used to form composite functions, and in 
turn, multiple composite functions may ultimately be specified. The user then 
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classifies each composite function, designating it either an objective function 
or a constraint function. Again, this distinction is solely for the optimiza- 
tion algorithm; Fun 3D simply evaluates and linearizes each of the composite 
functions in a generic sense and provides them to the optimization scheme. 

The adjoint formulation requires a separate adjoint solution for each com- 
posite function. For example, a drag-minimization problem with an explicit 
lift constraint will generally require two adjoint solutions at each step of the 
design procedure (one based on drag and one based on lift). Rather than per- 
forming separate adjoint executions for each function, Fun3D’s adjoint solver 
is implemented such that multiple adjoint solutions may be computed simulta- 
neously by cycling through a series of right-hand side vectors. In this manner, 
much of the computational overhead associated with discretizing the adjoint 
system is amortized over the collection of specified functions, and each addi- 
tional function only increases the overall computational cost by approximately 
40%. See [7] for further details on this aspect of the implementation. 

9.1.2 Functional Form 

Composite functions take the following general form in Fun3D: 


Here, the index Jj corresponds to the number of individual component func- 
tions comprising composite function i. The factor c Oj represents a user-specified 
weighting coefficient in the summation; Cj is a Fun 3D scalar output quantity, 
C* is a user-specified target value for that output quantity, and pj is a user- 
specified exponent. The currently available Fun 3D output functions that may 
be posed as Cj are listed in Table 10. Though not explicitly represented in 
Eq. 1, the implementation also allows the user to only use specific boundary 
contributions to Cj and not all boundaries if desired. This could be used to 
focus the optimization function on forces acting on the wing or tail only. Note 
that when composing an objective or constraint function it is often helpful 
to scale the expected value to an 0(1) quantity. This can be readily done 
using the ujj factor. Additional details relevant to more complex functions are 
covered in section 9.2. The specific input mechanism for providing each of 
the component/composite function parameters will be discussed at length in 
section 9.6.2. 

To demonstrate the use of the general functional form given by Eq. 1, 
several examples are given here: 

Unconstrained Drag Minimization For an unconstrained problem in 
which the user wishes solely to minimize drag, one potential approach might 



( 1 ) 
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Table 10: 

Keyword 

Objective/constraint component function keywords. 
Function 

cl, cd 

Lift, drag coefficients 

clp, cdp 

Lift, drag coefficients: pressure contributions 

civ, cdv 

Lift, drag coefficients: shear contributions 

cmx, cmy, cmz 

x/y/z-axis moment coefficients 

cmxp, cmyp, cmzp 

x/y/z-axis moment coefficients: pressure contributions 

cmxv, cmyv, cmzv 

x/y/z-axis moment coefficients: shear contributions 

cx, cy, cz 

x/y/z-axis force coefficients 

exp, cyp, czp 

x/y/z-axis force coefficients: pressure contributions 

cxv, cyv, czv 

x/y/z-axis force coefficients: shear contributions 

powerx, powery, powerz x/y/z-axis power coefficients 

eled 

Lift-to-drag ratio 

f om 

Rotorcraft figure of merit 

propeff 

Rotorcraft propulsive efficiency 

rtr_thrust 

Rotorcraft thrust function 

pstag 

RMS of stagnation pressure in cutting plane disk 

boom_targ 

Near-field p/poo pressure target 

sboom 

Coupled sBOOM ground-based noise metrics 

ae 

Supersonic equivalent area target distribution 

pressJbox 

RMS of pressure in user-defined box, also pointwise dp/dt, dp/dt 

cpstar 

Target pressure distributions 


be to specify a single composite function consisting of a single component 
function with uj\ = 1.0, Cj = cd, C / = 0.0, and pi = 2. In this manner, the 
objective function is simply 


/ 



( 2 ) 


where the quadratic form has been chosen to provide a convex function space. 


Drag Minimization with Lift Penalty To add an interior penalty term 
accounting for a lift equality constraint of 0.5, one might instead use two 
component functions within the same single composite function where = 
10.0, u >2 = 1.0, Ci = cd, C 2 = cl, C* = 0.0, C 2 = 0.5, and pi = P 2 = 2. These 
parameters yield 

/ = 10 Cl + (C L - 0.5) 2 . (3) 

In this case, any deviation of the lift coefficient from its target value of 0.5 
will “penalize” the objective function. The weighting parameters c Uj have been 
selected based on typical magnitudes of Cd and Cl, so as to produce roughly 
equivalent contributions to the objective function. Note that the choice of 
these weighting parameters is heuristic in nature and often troublesome in 
practice. 
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Drag Minimization with Explicit Lift Constraint In this example, the 
lift constraint Cl = 0.5 is instead posed as an explicit constraint for the opti- 
mizer. Here, two composite functions are formed, each with a single component 
function. First, an objective function is specified as in Eq. 2 with uj\ = 1.0, 
C\ = cd, Ci = 0.0, and p\ = 2. As before, this yields 

h = Cl (4) 

However, an additional composite function for the lift constraint is also spec- 
ified with lui = 1.0, C i = cl, Ci = 0.5, and pi = 1, which gives 


h = C L . (5) 

This explicit form of the lift constraint is generally preferred in practice. 

9.2 Some Details on Specific Objective/Constraint 
Functions 

Many of the scalar functions shown in Table 10 and designed to be used as the 
term Cj in Eq. 1 are straightforward. For example, the keyword cd is sufficient 
to characterize a drag-based component function. However, some of the scalar 
functions listed in Table 10 require the user to be aware of specific requirements 
and/or to provide additional auxiliary data. In this section, scalar functions 
requiring further data and/or explanation are covered. 

9.2.1 Lift-to-Drag Ratio (Keyword: clcd) 

This function must be specified with a 0 for its boundary index, i.e. , it must be 
applied to the entire configuration and is not available for individual boundary 
patches. It is defined as 

S=% ( 6 ) 

C'D 

9.2.2 Rotorcraft Figure of Merit (Keyword: f om) 

This function is defined as 


/ 


Cl 

2 C'li z 


(7) 


Note that this functional form assumes that the rotor axis of rotation is in 
the +z direction. The definition also represents the square of the traditional 
Figure of Merit function. See [13] for a motivation for this modified form. 
This function must be specified with a 0 for its boundary index, i.e., it must be 
applied to the entire configuration and is not available for individual boundary 
patches. 
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9.2.3 Rotorcraft Propulsive Efficiency (Keyword: propeff) 

This function is defined as 


/ 


~C Z 

Cm.. 


( 8 ) 


Note that this functional form assumes that the rotor axis of rotation is in 
the +z direction. The minus sign has been introduced to yield a positive 
efficiency since Cm , is negative. This function must be specified with a 0 for 
its boundary index, i.e., it must be applied to the entire configuration and is 
not available for individual boundary patches. 


9.2.4 Rotorcraft Thrust (Keyword: rtr thrust) 

This function is defined as the force normal to the plane of a rotor system: 

f = C L cos (9 t ) - C D sin(0 T ) (9) 

where the angle from + ^-direction 0 t in radians is the variable thrust_angle 
that must be set in the source hie LibF90/custom_transf orras.f 90. 


9.2.5 RMS of Stagnation Pressure (Keyword: pstag) 

This function computes the RMS of stagnation (total) pressure in a circu- 
lar disk that passes through the grid in a specified location and orientation. 
This is commonly employed to quantify engine inlet distortion. The user must 
specify the variables in the &pstag_function namelist within fun3d.nml. See 
section B.4.39 for details related to this namelist. This function is only avail- 
able for compressible hows. 

9.2.6 Near-field p/poo Pressure Target (Keyword: boom_targ) 

This function allows inverse design of near-held pressure signatures, which is a 
commonly used tactic for creating low sonic boom configurations. This func- 
tion is only available for compressible hows. The user specihes yz-coordinate 
pairs through which rays are passed parallel to the x-axis. Off-body pressure 
distributions in the vicinity of an aircraft are nominally oriented parallel to 
the freestream velocity vector. In the case of a nonzero angle of attack, the 
rays are rotated about a user-specihed center of rotation to align them with 
the freestream direction. The user also provides the minimum and maximum 
x-extent for the rays. A user-specihed number of points are evenly distributed 
along each ray and the grid element containing each point is identihed. See 
section B.4.35 for guidance on the required namelist inputs. 

The functional form is given by 
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( 10 ) 


where p is the local static pressure. The summation takes place over all points 

in the rays defined by the user, and the values of p are evaluated at the 

* 

centroids of the enclosing elements. The values of cu* and are user-supplied 


poiutwise weighting coefficients and target values of p/poo, respectively, which 
must be provided in a file named pressure_target.dat. If this file is not 
present, the target values of p/poo are set to 1.0 and the weighting coefficients 
are set to 1.0. Note that with the above functional form, the target and 
exponent parameters present in Eq. 1 are usually set to 0.0 and 1, respectively. 

A template for pressure_target.dat is typically generated by first extract- 
ing a set of p/poo distributions for a known configuration by running the op- 
timization driver with what_to_do = 1 in the design. nral &design namelist, 
see section 9.5.1. Note that the input value weight must be set to .true, 
and the desired ray extraction (y, z ) coordinate pairs must be specified in the 
&sonic_boom namelist in fun3d.nral. This operation produces a file named 
pressure_signatures.dat, which uses the same file format intended for the 
pressure_target.dat target input file. (Note that the file format is amenable 
to Tecplot™ usage.) The user may then use the pressure_signatures.dat 
file to develop a pressure_target.dat input file by modifying the existing 
pressures to reflect their target values as desired. Note that by specifying 
weight=.true . in the &sonic_boom namelist, a column of data representing 
pointwise weighting coefficients (all initially set to 1.0) will be provided in 
pressure_signatures.dat. This column of data is required to be present in 
pressure_target.dat. The individual weights may be left as 1.0, or they 
may be modified on an individual basis to optionally weight a specific region 
of the signature more or less in the final objective function. A brief example 
of this file format for a case involving two off-body signatures is shown below. 
Note that target distributions need not have the same number of locations as, 
nor line up with, the eventual sampling locations along the extraction rays. 
Fun3D will linearly interpolate between input target values to obtain values 
at the sampling locations. 


VARIABLES = "x" , "y" , "z", "p/pinf", "weight" 
zone t="Signal 1" 

-0 . 500E+01 0 . 100E-11 0 . 826E+00 0.110010E+01 0.100E+01 
-0 . 472E+01 0 . 100E-11 0.835E+00 0.110011E+01 0.100E+01 
-0 . 415E+01 0 . 100E-11 0 . 855E+00 0.110012E+01 0.100E+01 
-0 . 354E+01 0 . 100E-11 0.876E+00 0.110016E+01 0.100E+01 
zone t="Signal 2" 

-0 . 500E+01 0 . 100E-11 0 . 182E+01 0.102008E+01 0.100E+01 
-0 . 472E+01 0 . 100E-11 0.183E+01 0.102008E+01 0.100E+01 
-0 . 414E+01 0 . 100E-11 0 . 185E+01 0.102009E+01 0.100E+01 
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-0 . 356E+01 0 . 100E-11 0.187E+01 0.102012E+01 0.100E+01 
-0 . 335E+01 0 . 100E-11 0.188E+01 0.105013E+01 0.100E+01 
-0 . 320E+01 0 . 100E-11 0.188E+01 0.105014E+01 0.100E+01 
-0 . 264E+01 0 . 100E-11 0.190E+01 0.105017E+01 0.100E+01 

9.2.7 Coupled sBOOM Ground-Based Signatures, Noise Metrics, 
and Equivalent Areas (Keyword: sboom) 

This option uses the adjoint capability of the Burgers equation boom prop- 
agation code SBOOM [14] to inversely design ground pressure signatures, 
optimize a ground-based noise metric, or match equivalent area distributions. 
[15-17] Fun 3D must be configured and built with the sBOOM library as 
described in section A. 7. 14 to use this capability. 

In the coupled Fun3D-sBOOM implementation, Fun3D is responsible 
for computing pressure signals in the immediate vicinity of an aircraft (typi- 
cally within 10 body lengths). The sBOOM tool then propagates these dis- 
turbances to the ground using an augmented Burgers equation that considers 
effects such as non-linearity, thermo-viscous absorption, and any number of 
molecular relaxation phenomena during the propagation of waveforms through 
the atmosphere. In this manner, the user can directly simulate ground-based 
noise metrics such as A-weighted loudness or compute other loudness measures 
(e.g., Perceived Level) from the computed ground signatures. In a similar fash- 
ion, a coupled adjoint problem is used to determine the discrete sensitivities 
of the ground-based metrics with respect to any of Fun3D’s typical design 
parameters which may then be used to optimize the configuration. 

SBOOM can generate off-track signatures based on ray theory using user 
input azimuthal angles. SBOOM can also predict the sonic boom signatures 
in the presence of wind, turn rate (changing heading angle), climb rate, climb 
angle, and acceleration (dMach/dt). During maneuvering flight, boom focus- 
ing is possible. The current version SBOOM in not able model focusing and 
will exit with an appropriate message if focusing occurs. 

Equivalent area distributions are computed with reversed augmented Burg- 
ers equation (when rs< (alt— hg)) or a direct conversion of off-body pressures 
(when rs> (alt— hg)). This is different than the Mach cut equivalent area 
matching approach in section 9.2.8. The discrete sensitivities of the difference 
between a target and the computed equivalent areas are provided to Fun 3D. 
The target area is specified with the target.dpress and target_xx variables 
in the fesboom namelist. 

The user must provide inputs relevant to the nearfield pressure signal ex- 
traction (see section B.4.35) as well as parameters specific to the sBOOM 
library (see section B.4.36). Note that when the sboom keyword is used as 
the component function name, the actual form of the objective/constraint 
component function is determined entirely within SBOOM. In this case, the 
values of u, C*, and p in Eq. 1 are ignored. This function is only available for 
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compressible flows. 


9.2.8 Supersonic Mach Cut Equivalent Area Distribution 
(Keyword: ae) 

This function aims to match a target Mach cut equivalent area distribution for 
supersonic flows. The Mach cut equivalent area distribution is directly com- 
puted from surface pressures and geometry for this function. This is a different 
approach than the equivalent area computation of sBOOM in section 9.2.7. 
The function is defined as 


where N represents the total number of longitudinal stations used to sample 
the solution and geometry for the current azimuth, and L,- and Vi are the lift 
and volume contributions, respectively, to the current equivalent area. The 
term A* represents the user-supplied target equivalent area distribution. The 
uji enables the user to locally weight individual segments of the distribution 
if desired. Note that with the above functional form, the target and expo- 
nent parameters present in Eq. 1 are usually set to 0.0 and 1, respectively. 
This function is only available for compressible flows, and the configuration is 
assumed to align with the x-axis. 

Any number of desired azimuthal (centerline/off-track) locations may be 
specified and used as individual component functions. The user must pro- 
vide the data indicated in the &equivalent_area namelist in fun3d.nml as 
described in section B.4.37. A centerline symmetry plane may be used to 
reduce computational expense; in this case, the cutting planes at each longitu- 
dinal station will be correctly accounted for on the virtual side of the aircraft. 
A hie ae_target.dat must also be provided, which describes the (optionally 
weighted) target equivalent area profiles. 

A template for ae_target.dat is typically generated by first extracting a set 
of equivalent area distributions for a known configuration by running the opti- 
mization driver with what_to_do = 1 in the design. nml fedesign namelist, see 
section 9.5.1. This operation will produce a Tecplot™ hie [projectxrootname] 
_ae.dat which uses the same hie format intended for the target input hie 
ae_target.dat. The user may then use the [pro j ect_rootname] _ae.dat hie to 
develop a ae_target.dat input hie by modifying the existing equivalent areas 
to rehect their target values as desired. Note that the hie [project_rootname] 
_ae.dat contains a column of data representing the pointwise weighting coeffi- 
cients Ui (all initially set to 1.0). This column of data is required to be present 
in ae_target.dat. The individual weights may be left as 1.0, or they may be 
modified on an individual basis to optionally weight a specihc region of the 
distributions more or less in the final objective function. A brief example of 
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this file format for a case involving three azimuthal signatures is shown below. 
Note that target distributions need not have the same number of locations as, 
nor line up with, the longitudinal sampling locations. Fun3D will linearly 
interpolate between input target values to obtain values at the sampling lo- 
cations. Also note that in the input hie ae_target.dat, the second and third 
columns of the format are ignored. 


VARIABLES = "x" , "V", "L" , "Ae", "weight" 
zone t="Ae Function 1" 


-0 . 01000E+00 
0 . 13839E+01 
0 . 27678E+01 
0 . 41517E+01 


0 . 00000E+00 
0 . 25482E-01 
0 . 47548E-01 
0 . 76165E-01 


0 . 00000E+00 
-0 . 26289E-02 
-0 . 64155E-02 
-0 . 10361E-01 


0 . 00000E+00 
0 . 22853E-01 
0.41133E-01 
0 . 65804E-01 


zone t="Ae Function 2" 


0. 10000E+01 
0. 10000E+01 
0. 10000E+01 
0. 10000E+01 


-0 . 01000E+00 
0 . 14018E+01 
0 . 28036E+01 
0 . 42054E+01 
0 . 56072E+01 
0 . 98126E+01 


0 . 00000E+00 
0 . 25700E-01 
0.48215E-01 
0 . 7T379E-01 
0 . 11457E+00 
0 . 30728E+00 


0 . 00000E+00 
-0 . 26610E-02 
-0 . 64628E-02 
-0 . 10358E-01 
-0 . 14045E-01 
-0 . 25T26E-01 


zone t="Ae Function 3" 


-0 . 01000E+00 
0. 14155E+01 
0 . 28310E+01 
0 . 42465E+01 


0 . 00000E+00 
0 . 26009E-01 
0.48902E-01 
0 . 78591E-01 


0 . 00000E+00 
-0 . 26166E-02 
-0 . 62883E-02 
-0 . 10011E-01 


0 . 00000E+00 
0 . 23039E-01 
0 . 41752E-01 
0 . 67020E-01 
0 . 10052E+00 
0 . 28156E+00 

0 . 00000E+00 
0 . 23392E-01 
0 . 42614E-01 
0 . 68579E-01 


0. 10000E+01 
0. 10000E+01 
0. 10000E+01 
0. 10000E+01 
0 . 10000E+01 
0. 10000E+01 

0. 10000E+01 
0. 10000E+01 
0. 10000E+01 
0. 10000E+01 


Finally, the solver will also provide the user with a Tecplot lM output hie 
[project_rootname] _ae_cuts_i.dat for the ith specihed equivalent area func- 
tion. These hies contain the actual cross-sectional slices of the aircraft that 
were generated for each azimuthal function. 


9.2.9 RMS of Pressure in User-Defined Box, Pointwise dp/dt , 
dp/dt (Keyword: press box) 

This function computes the RMS of a quantity in Cartesian region, which is 
typically used to indicate a region of the how is important for grid adaptation 
or that fluctuations in a region should be minimized in a design. These func- 
tions rely on the inputs associated with the &press_box_function namelist; 
see section B.4.38 for details. The function may be composed of the RMS 
value of the pressure within a user-defined box in the domain, or for unsteady 
simulations, the time derivative of pressure or density (for compressible hows) 
at a single grid point. 


9.2.10 Target Pressure Distributions (Keyword: cpstar) 

Fun 3D has an inverse design capability where the objective function may 
be composed of target pressure distributions. The file containing the jth 
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target distribution must be named cpstar.data.j. However, setup is te- 
dious, primarily due to the difficulty in specifying pressure distributions on 
a three-dimensional configuration. If this capability is of interest, please con- 
tact Fun3D-Support@lists.nasa.gov for more detailed guidance. 

9.3 Geometry Parameterizations 

In order to perform shape optimization, Fun3D must be provided with a set of 
design variables describing the geometric shape of the configuration. Fun3D is 
currently set up to interface directly with geometry parameterizations provided 
by MASSOUD [18], Bandaids [19], or Sculptor M . MASSOUD and Bandaids 
are software packages developed by Jamshid Samareh of NASA Langley. Users 
may contact Fun3D-Support@lists.nasa.gov for copies of the software; tu- 
torial information for these tools is available on the Fun3D website. These 
packages allow the user to parameterize completely arbitrary shapes using a 
free-form deformation technique. The packages are very efficient, robust, and 
also provide analytic Jacobians of the parameterization, which are necessary 
for FuN3D-based design. Sculptor™ is a popular commercial package devel- 
oped by Optimal Solutions and also provides the necessary data for Fun3D- 
based design. Note that any combination of parameterizations based on these 
tools may be used within the context of a single optimization. For example, 
the planform of a wing or tail surface may be best treated using MASSOUD, 
while Bandaids or Sculptor M may be most appropriate for a wing-body fillet 
region or a feature such as a fuselage protuberance. Finally, the user may also 
use a parameterization scheme of their choosing; see section section 9.3.4 for 
further details. 

9.3.1 Surface Grid Extraction 

To parameterize a surface grid using any of the above tools, it must first be 
extracted to a Tecplot™ file. To do this, add a &massoud_output namelist 
to fun3d.nml to group all of the required boundary patches for a body to be 
parameterized into a single body (see also section B.4.34): 

&massoud_output 
n_bodies = 2 
nbndry(l) = 6 
boundary_list (1) = '3-8' 
nbndry(2) = 3 

boundary_list (2) = '9,10,12' 

/ 

Note that the boundary indices shown here must reflect any patch lump- 
ing that may have been requested in the &raw_grid namelist (see also sec- 
tion B.4.2). A single iteration of the flow solver should now be executed 


parameterize 2 bodies: wing and tail 

# of bounds that comprise wing 
wing bounds (account for lumping!) 

# of bounds that comprise tail 
tail bounds (account for lumping!) 
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with the — write_massoud_f ile command line option. This will generate a 
[pro j ect_rootname] _massoud_bndry#.dat hie for each of the boundary groups 
present in the &massoud_output namelist. These hies contain the information 
necessary to parameterize the surface grid using any of the aforementioned 
tools. See the documentation for those packages for further instructions on 
how to construct the actual parameterization. 

9.3.2 Access to Executables 

If MASSOUD, Sculptor M , or a user-dehned executable is being used for pa- 
rameterizations, the executable for those packages must be available in the 
runtime PATH. The executables for MASSOUD and Sculptor M must be named 
massoud and sculptor, respectively. If using a user-dehned parameterization 
package (see section 9.3.4), the executable must be named according to the 
input provided in the &design namelist in design. nml (see section 9.5.1). The 
optimization driver supplied with Fun3D will attempt to call these executa- 
bles if such parameterization types are present. If Bandaids are being used, no 
additional executables must be supplied; all Bandaid evaluations are handled 
internally by Fun3D. 

9.3.3 Notes on Using Sculptor™ 

If Sculptor M is being used, Fun3D will invoke Sculptor M in batch (non-GUI) 
mode during the course of the optimization. However, current versions of 
Sculptor™ will still attempt to communicate with an X server, even when run 
in this fashion. If the system does not run an X server (such as compute nodes 
on a cluster), then a fake X server such as Xvfb is recommended. You will 
need to execute the fake server prior to running the design optimization. For 
example, a run script may have the following commands: 

Xvfb : 1 & 

export DISPLAY=:1.0 # for bash 

setenv DISPLAY : 1 . 0 # for c shell 

[any command that uses Sculptor] 

The syntax here may vary; if this does not allow the optimization driver to 
run Sculptor M in batch mode successfully on the system, the user should get 
in touch with Sculptor M support for assistance. 

In addition, the parameterization of all bodies treated using Sculptor™ 1 
must be bookkept within a single set of Sculptor M input hies. For example, 
in the wing-tail example above, both bodies must be contained in a single in- 
stance of Sculptor M hies. Therefore, the &massoud_output namelist described 
above should group all of the desired boundaries necessary to describe the 
geometry(s) of interest into a single body: 
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&massoud_output 
n_bodies = 1 
nbndry(l) = 9 


wing and tail grouped into a body 
# of tail and wing bounds 
wing and tail boundaries 


boundary_list (1) = '3-10,12 


/ 


Each of the desired bodies may be worked on independently within Sculp- 
tor, but they must ultimately appear as a single body to Fun3D. 

9.3.4 Using Other Parameterization Packages 

Fun 3D provides a generic interface for user-defined external geometric pa- 
rameterization packages. The user-defined tool must provide the surface mesh 
coordinates as a function of some vector of design variables for the body of 
interest. The partial derivatives of these coordinates with respect to the design 
variables must also be supplied. See [20] for an example of such an approach. 

To invoke a user-defined parameterization package for one or more bod- 
ies present in the simulation, the user must tag individual bodies appropri- 
ately (see section 9.6.2) and provide the executable name to be invoked by 
Fun3D’s design driver at run-time via the &design namelist in design. nral 
(see section 9.5.1). This may be a binary executable or simply a script that 
invokes other user-defined operations that may be necessary to evaluate the 
parameterization and its sensitivities. 

When Fun 3D requires an evaluation of the user-defined parameterization 
for a body (or its sensitivities), it will first write a file named custoraDV.i, where 
the i suffix corresponds to the body index for which Fun 3D is requesting 
updated surface data. The format of the customDV.i hie is as shown below. 

#User defined design variables 
#Number of DVs 


1 . 907460000000000E+00 
0 . 000000000000000E+00 
-0 . 002469800000000E+00 

The Erst two lines are comment lines, and the third specifies the total number 
of design variables in the parameterization for the current body (whether the 
user may have designated some active and others inactive in rubber. data; see 
section 9.6.2). The remaining lines in the hie contain the current value of each 
design variable, with one value per line. 

After writing the customDV.i hie, Fun 3D will then invoke the user-specihed 
executable command. Fun 3D will append a space and a single integer to this 
command, where the integer corresponds to the body index for which Fun 3D 
requires an evaluation of the parameterization. The user-provided executable 
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(or script) must be capable of parsing this integer command-line option in 
order to process the requested body. 

After the external package has completed the evaluation of the parameteri- 
zation and its sensitivities, the data must be supplied to Fun 3D via a Tecplot™ 
hie named model. tec. i.sdl, where the integer i in the filename represents the 
current body index. The format of this hie must be as follows: 

TITLE = "PARAMETERIZATION DATA" 

VARIABLES = "X" "Y" "Z" "ID" "XDl" "YD1" "ZD1" "XD2" "YD2" "ZD2" "XD3" "YD3" "ZD3" 

ZONE T = groupO, I = 4, J = 1, F=FEP0INT 

0.0 1.0 0.0 235 1.234 -23.0 892.1 -23.0 82.123 -90.2 -905.2 857.12 348.2 
1.0 1.0 0.0 872 4.14 -0.123 -0.324 23.13 2978.2 -0.114 -982.4 -3.22 0.1185 
1.0 0.0 0.0 912 -0.34 0.938 8.45 78.23 -35.2 -0.023 8.32 -0.009 -0.92 
0.0 0.0 0.0 455 9.01 -8.23 -0.456 2.56 1.21 0.0 -0.091 -1.22 0.0088 
12 3 4 

The trivial (and completely contrived) example shown here provides sur- 
face mesh point locations and the corresponding sensitivities for a single quad 
element parameterized by three design variables. The title in the hrst line may 
contain anything the user desires. The variables identified in line 2 represent 
the x-, y-, and z-coordinates for the current surface mesh point, the node in- 
dex in the global grid for the current surface mesh point, and the sensitivity 
derivatives of the x-, y-, and z-coordinates of the current surface mesh point 
with respect to each of the design variables provided by Fun3D in customDV.i 
above. The hie should contain a single zone, indicated by the third line of the 
example hie shown. Here, the zone title specihed by T = may be anything the 
user desires. The I = value corresponds to the number of surface mesh points 
for the current body, while the J = value specihes the number of surface ele- 
ments (triangles or quads) contained in the surface mesh for the current body. 
Fun3D will only read the I = value; the surface mesh topology is immaterial 
in this context. 

In this example, the floating point values have been truncated for read- 
ability; users are strongly encouraged to provide double-precision values in 
practice. The connectivity information at the end of the hie is not used by 
Fun3D. It may be omitted if desired; however, it is often instructive to load 
this hie into Tecplot™ for visualization. In that context, the connectivity data 
(including the appropriate J = value in the hie header) will be required. 

For very large surface meshes and/or parameterizations containing a very 
large number of design variables, I/O of this ASCII format can be inefficient. 
There is an alternative C-binary /Fortran stream format that may be used in its 
place; interested users should get in touch with Fun3D-Support@lists . nasa . gov 
for further details on this option. 

To support execution of the user-defined parameterization tool, auxiliary 
hies may be provided in the description.! directory; the filenames should 
be provided in the hie user.def _param_f iles.data (see section 9.6.1). 
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9.4 Design Optimization Directory Structure 

The optimization driver opt_driver requires a very specific directory struc- 
ture. It can be established by running opt_driver in an interactive mode 
with the — setup_design command line option. The number of design points 
should be 1 for single-point design or greater than 1 for multi-point design. 

opt_driver — setup_design [number of design points] 

This interactive command will prompt the user for several directory paths 
required by the optimization, namely the paths to the Fun 3D source code, 
the configuration directory where Fun 3D was configured and built, and the 
path to the location where the design will be performed. Here, directories 
should be provided as absolute paths contained in single quotes, with trailing 
slashes omitted, i.e. , 

' /absolute/path ' 

At the completion of this setup procedure, a summary of the hies required 
from the user will be echoed to the screen. The directories created in the 
specified run location are shown in Table 11. The i suffix in description.! 


Table 11: Directory structure required for FuN3D-based design. 

Directory Description 

ammo Location where optimization will be executed 

description. i Location of all baseline input files describing design point i 

model. i Location where analysis & sensitivity analysis of design point i will be performed 

and model, i represents the design point index. For single-point design, this 
will be 1; for multi-point design, this value will range from 1 to the number 
of user-specified design points. The setup procedure will populate the various 
directories with links to the required Fun 3D executables and templates for 
various input hies described below. 

9.5 Contents of the ammo Directory 

The ammo directory will contain hies related to the optimization procedure 
itself. This includes the design. nml input hie described in section 9.5.1 and a 
link to the opt_driver executable. 

9.5.1 &:design namelist in design.nml 

This namelist contains variables that specify inputs relevant to running de- 
sign optimization. While many of the default values for the variables in this 


namelist may be acceptable, at a minimum, the user will need to specify 
what_to_do and provide the base.directory name in which the case is to be 
executed. 


fedesign 


what_to_do 

= 

1 

restart_optimization 

= 

.false . 

previous_evaluations 

= 

0 

max_design_cycles 

= 

10 

base_directory 

= 

1 1 

n_design_pts 

= 

1 

design_pt_weight ( : ) 

= 

1.0 

opt_algorithm 

= 

4 

max_function_evals 

= 

20 

tau_subproblem 

= 

1.0e-4 

f eas_tol_val 

= 

1.0e-3 

dot_method 

= 

1 

user_def _executable 

= 

1 1 

body_grouping 

= 

.false . 

n_body_tr ansf orms 

= 

0 

body_transf orms ( : ) 

= 

0 

mpirun_pref ix 

= 

'mpiexec 

adjoint_nproc 

= 

0 


what_to_do = 1 

This is the operation performed by the optimization driver. 

‘ 1 J only performs the function evaluation. 

‘ 2 J performs the function evaluation and sensitivity analysis. 

‘ 3 J performs optimization. 
restart_optimization = .false. 

This logical specifies whether to start the optimization from the baseline 
problem description or to restart the optimization from a previous run 
already executed in this directory. 

previous.evaluations = 0 

Number of previous evaluations when restart_optiraization=.true. for 
which history hies have been saved. Several hies are saved with each func- 
tion/sensitivity evaluation (convergence history, surface history, etc.) by 
appending the evaluation number to the end of the hie name. This 
previous.evaluations allows the previous history hies to remain to 
maintain a contiguous history for the optimization. See section 9.6.7 for 
details on this archiving scheme. 
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max_design_cycles = 10 


This scalar integer sets an upper limit on the number of design cycles 
the optimizer may perform. 

base.directory = 5 ’ 

This string should be an absolute path to the design location specified 
during the setup procedure. Path should be enclosed in single quotes 
and contain no trailing slashes. 

n_design_pts = 1 

This scalar integer is the number of design points to be considered during 
the optimization. The value should be at least 1 and less than or equal 
to the number of design points specified during the setup procedure. 

design_pt_weight ( : ) = 1.0 

A non-negative real-valued scalar should be specified for each design 
point. The value represents the weighting to be applied in the linear com- 
bination of objective functions from each individual design point as used 
to construct the final composite objective function (see section 9.10). 
For single point optimization, a single value of 1.0 should be specified. 

opt.algorithm = 4 

This integer specifies the optimizer to be used. Fun3D must be config- 
ured and built with the specified optimization library. See section A. 7 
for more information on obtaining installing the optimizers. 

‘ 1 ’ utilizes the DOT/BIGDOT M optimizer. 

c 3’ utilizes the KSOPT optimizer. 

‘4 J utilizes the PORT optimizer. 

‘ 5 J utilizes the NPSOL M optimizer. 

‘6’ utilizes the SNOPT M optimizer. 

max_function_evals = 20 

This scalar integer is only relevant for PORT-based optimizations and 
sets an upper limit on the number of flow solutions allowed during the 
design. 

tau.subproblem = 1.0e-4 

This scalar real value is only relevant for DOT/BIGDOT M - and PORT- 
based optimizations and specifies the relative function convergence cri- 
terion for which the optimization will terminate. 
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feas_tol_val = 1.0e-3 


This scalar real value is only relevant for optimizations based on the 
DOT/BIGDOT™, NPSOL™, and SNOPT™ packages. The value specifies 
the feasibility tolerance for constraints. 

dot_method = 1 

This scalar integer is only used for DOT /BIGDOT M -based optimization 
and specifies the optimization method to be used with DOT /BIGDOT M . 
See the DOT /BIGDOT M documentation for further information. 

user.def .executable = ’ ’ 

This string enclosed in single quotes represents the name of the exe- 
cutable (or script) to be launched if user-defined geometric parameteri- 
zations are to be used. The executable should be available in the users 
PATH. See also section 9.3.4. 

body .grouping = .false. 

This logical specifies whether any body grouping should be applied. See 
also section 9.6.4. 

n.body .transforms = 0 

This scalar integer specifies the number of MASSOUD-parameterized 
bodies for which spatial transforms should be applied. See also sec- 
tion 9.6.10. 

body.transf orms ( : ) = 0 

These integers specify the MASSOUD-parameterized bodies to which 
spatial transforms are to be applied. There should be n.body .transforms 
entries supplied. If n.body .transforms is zero, this line of data should 
not be present. See also section 9.6.10. 

mpirun.pref ix = ’ mpiexec’ 

This string enclosed in single quotes will be used as a prefix when running 
MPI programs. This is usually mpirun or mpiexec, depending on the 
MPI implementation, or perhaps aprun on Cray® systems. 

adjoint_nproc = 0 

This scalar integer specifies the number of processors on which to execute 
the adjoint solver. Most often, this is the same number of processors 
requested for the job and the value used for the flow solver. However, 
in the event that a split communicator is being used for the flow solver 
(e.g., for simultaneous execution of Suggar++, Visit, dedicated Hie I/O, 
etc), the actual flow solution will be performed on some subset of the 
cores dedicated to the overall job. In this case, the adjoint solver must 
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be forced to execute on the same reduced number of cores, which is 
specified using this input, ff the value of adjoint_nproc is set to 0, then 
the adjoint solver will be executed on the total number of processors 
allocated to the overall job. 

9.6 Contents of the description.! Directory 

The descriptions directory serves as a repository for the baseline hies for 
the CFD model, the geometric parameterization, and several other input hies 
related to the computational model for the ith design point. These hies must 
be set up by the user prior to the run and will not be modified by Fun 3D dur- 
ing execution. During the initial setup procedure, templates for several input 
hies will be placed in this location to aid in setting up the case. During the 
actual optimization, the optimization driver will copy hies from this directory 
into the model . i directory as needed. 

Any hies normally required by the how solver must be present in this 
directory. This would typically include the grid and boundary condition hies 
and fun3d.nml. If the mesh uses overset grids assembled with the Suggar++ 
utility, the Suggar++ DCI hie must be present as well. The optional hie 
remove_boundaries_from_f orce_totals (section B.3) may also be present, if 
desired. 

In addition to the hies normally required by the how solver, a number of 
other hies must also be present to perform the design optimization, some of 
which are optional. These are described below. 

9.6.1 Geometry Parameterization Files 

If performing shape optimization, the user must provide the relevant parame- 
terization hies for each body in the mesh to be modified. The specihc set of 
hies required for each body depends on the parameterization package(s) being 
used. 

MASSOUD Parameterizations For MASSOUD parameterizations, the 
MASSOUD parameterization hies should be named design. gp.j, where j is 
the index of the body to be designed. The hies specifying the values of the 
raw MASSOUD variables should be named design, j for each of the bodies 
to be designed. For FuN3D-based design, the custom design variable linking 
feature of MASSOUD must be used. If the raw MASSOUD variables are 
intended to be used as-is, simply set the linking matrix as the identity matrix 
in the MASSOUD .usd hie. These hies specifying the design variable linking 
for each body should be named design. usd. j . 

The MASSOUD control hie specihes the names of the hies outlined above 
for MASSOUD and must be provided as massoud.j for the jth body. The 
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files listed in the MASSOUD control file must reflect these names. The first 
line of the MASSOUD control hle(s) must have a positive integer equal to 
the number of custom design variables. If the intent is simply to use the raw 
MASSOUD variables as-is, this value is simply the number of raw MASSOUD 
variables for that body. For the in/out-of-core parameter, use in-core (0). 
The hie name for Tecplot™ output viewing must be named model. tec. j for 
the jth body. The design variable grouping hie specihed should be named 
designVariableGroups. j for the jth body. The FAST output hie name can be 
named anything the user wishes; the Fun3D tools do not use this MASSOUD 
output hie. Finally, the user design variable hie for the jth body should be 
named customDV.j. In summary, a massoud.j control hie for the jth body 
should look like the following: 


#MASS0UD INPUT FILE 

# runOption O-analysis, >0-sd users dvs, -1-sd massouds dvs 
52 

# core 0-incore solution, 1-out of core solution 
0 

# input parameterized file 
design. gp. 1 

# design variable input file 
design. 1 

# input sensitivity file - used for runOption > 0 
design. usd. 1 

# output file grid file 
newf rame .fast . 1 

# output Tecplot file for viewing 
model . tec . 1 

# file containing the design variables group 
designVariableGroups . 1 

# user design variable file 
customDV . 1 


Bandaid Parameterizations For Bandaid parameterizations, the input 
hies created by the Bandaid setup tool should be named bandaid. data. j for 
the jth body. Because Bandaid parameters behave linearly, the sensitivities 
contained in these hies are constant and this input is all that is required during 
the course of a design. 

Sculptor™ Parameterizations For Sculptor M parameterizations, the user 
must provide [project_rootname] .mdf , [project_rootname] .sdl, [project_rootname] 
.vol, and [project_rootname] .stu hies. See the Sculptor M documentation 
for more details on each of these hies. A hie named [project_rootname] .def 


73 



must also be provided. An example [projectvrootname] .def file for a simple 
two-body parameterization is shown below: 


set_mdf [project_rootname] .mdf 
default 1 DV1-T1 0.00 
default 1 DV1-T2 0.00 
default 1 DV1-T3 0.00 
default 1 DV1-T4 0.00 
default 1 DV1-T5 0.00 
default 2 DV2-T1 0.00 
default 2 DV2-T2 0.00 
default 2 DV2-T3 0.00 
export model. tec. 1 
exit 


The filename specified for the export command must be model.tec.l. The 
remainder of the hie is dictated by the specific parameterization developed in 
the Sculptor M application. 

After the configuration has been parameterized using Sculptor M and all of 
the appropriate hies have been assembled for FuN3D-based design, a copy 
of the original [project_rootname] _massoud_bndry#.dat hie must also be 
placed in the description.! directory, but with the hie name changed to 
[project_rootname] .sdl. Sculptor™ requires this baseline hie during the op- 
timization. 

Finally, prior to performing the design, the [project_rootname] .sdl hie 
must be read into Sculptor M in GUI mode as “Import Mesh/CFD as Tec- 
plot Point FE.” Following this, the Sculptor volumes need to be imported 
onto the [project_rootname] .sdl hie, and then the model must be saved 
again. Once this is done, the command export model.tec.l within the 
[project_rootname] .def batch script will generate a model.tec.l. sdl hie as 
needed for FuN3D-based design optimization. 


User-Defined Parameterizations In the event that a user-dehned geo- 
metric parameterization package is to be used, the user must provide a hie 
user.def _param_f iles.data. Since Fun3D will not be aware of any auxiliary 
hies that may be needed by the user-dehned parameterization package, those 
hies should be listed here, with a single hie name per line. Each hie named 
here must be provided by the user. At run time, Fun3D will move the named 
hies to the appropriate location prior to execution of the parameterization ex- 
ecutable indicated by the user in the fedesign namelist in design. nml. See 
also section 9.3.4 and section 9.5.1. 
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9.6.2 rubber, data 


This section describes how to set up each block of the design control hie 
rubber. data. The template provided in the Adjoint directory of the source 
code distribution is installed in the description.! directory during setup. 
This hie serves as the primary control hie during the course of the optimiza- 
tion and stores all of the high-level information relevant to the design. The hie 
is repeatedly read and updated by the various tools during the design proce- 
dure. A simple example of this hie to be used for discussion purposes is shown 
below. 


################################################################################ 
########################### Design Variable Information ######################## 
################################################################################ 
Global design variables (Mach number, AOA, Yaw, Noninertial rates) 


Var 

Active 

Value 

Mach 

0 

0 . 800000000000000E+00 

AOA 

1 

1 . 000000000000000E+00 

Yaw 

0 

0 . 000000000000000E+00 

xrate 

0 

0 . 000000000000000E+00 

yrate 

0 

0 . 000000000000000E+00 

zrate 

0 

0 . 000000000000000E+00 


Lower Bound 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 


Upper Bound 
0 . 900000000000000E+00 
5 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 


Number of bodies 


2 


Rigid motion design variables for 'wing' 


Var Active 

Value 

RotRate 

0 

0 . 000000000000000E+00 

RotFreq 

0 

0 . 000000000000000E+00 

RotAmpl 

0 

0 . 000000000000000E+00 

RotOrgx 

0 

0 . 000000000000000E+00 

RotOrgy 

0 

0 . 000000000000000E+00 

RotOrgz 

0 

0 . 000000000000000E+00 

RotVecx 

0 

0 . 000000000000000E+00 

RotVecy 

0 

0 . 000000000000000E+00 

RotVecz 

0 

0 . 000000000000000E+00 

TrnRate 

0 

0 . 000000000000000E+00 

TrnFreq 

0 

0 . 000000000000000E+00 

TrnAmpl 

0 

0 . 000000000000000E+00 

TrnVecx 

0 

0 . 000000000000000E+00 

TrnVecy 

0 

0 . 000000000000000E+00 

TrnVecz 

0 

0 . 000000000000000E+00 


Lower Bound 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 


Upper Bound 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 


Parameterization Scheme (Massoud=l Bandaids=2 Sculptor=4 User-Def ined=5) 


1 


Number of shape variables for 'wing' 
3 


Index Active Value 


Lower Bound 


1 

2 

3 


1 1.000000000000000E+00 
1 1.000000000000000E+00 
1 1.000000000000000E+00 


0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 


Rigid motion design variables for 'tail' 
Var Active Value 


Lower Bound 


RotRate 0 
RotFreq 0 
RotAmpl 0 
RotOrgx 0 
RotOrgy 0 
RotOrgz 0 
RotVecx 0 
RotVecy 0 
RotVecz 0 
TrnRate 0 


0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 


0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 


Upper Bound 
2 . 000000000000000E+00 
2 . 000000000000000E+00 
2 . 000000000000000E+00 


Upper Bound 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
0 . 000000000000000E+00 
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TrnFreq 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnAmpl 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnVecx 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnVecy 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

TrnVecz 0 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 0 . OOOOOOOOOOOOOOOE+OO 

Parameterization Scheme (Massoud=l Bandaids=2 Sculptor=4 User-Def ined=5) 

2 

Number of shape variables for 'tail' 

2 

Index Active Value Lower Bound Upper Bound 

1 1 2. OOOOOOOOOOOOOOOE+OO -1 . OOOOOOOOOOOOOOOE+OO 5. OOOOOOOOOOOOOOOE+OO 

2 1 2. OOOOOOOOOOOOOOOE+OO -1 . OOOOOOOOOOOOOOOE+OO 5 . OOOOOOOOOOOOOOOE+OO 

################################################################################ 
############################### Function Information ########################### 
################################################################################ 
Number of composite functions for design problem statement 

2 

################################################################################ 
Cost function (1) or constraint (2) 

1 

If constraint , lower and upper bounds 

0.0 0.0 

Number of components for function 1 
1 

Physical timestep interval where function is defined 
1 1 

Composite function weight, target, and power 

1.0 0.0 1.0 

Components of function 1: boundary id (0=all) /name/value/weight/target/power 
0 cl 0.000000000000000 1.000 10.00000 2.000 

Current value of function 1 
0.000000000000000 

Current derivatives of function wrt global design variables 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt shape design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 2 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
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0.000000000000000 

0.000000000000000 

0.000000000000000 

0.000000000000000 

0.000000000000000 

0.000000000000000 

0.000000000000000 

0.000000000000000 

0.000000000000000 

0.000000000000000 

Current derivatives of function wrt shape design variables of body 2 
0.000000000000000 
0.000000000000000 

################################################################################ 
Cost function (1) or constraint (2) 

2 

If constraint , lower and upper bounds 
-0.03 -0.01 

Number of components for function 2 
1 

Physical timestep interval where function is defined 
1 1 

Composite function weight, target, and power 

1.0 0.0 1.0 

Components of function 2: boundary id (0=all) /name/value/weight/target/power 
0 cmy 0.000000000000000 1.000 0.00000 1.000 

Current value of function 2 
0.000000000000000 

Current derivatives of function wrt global design variables 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt shape design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 2 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
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0.000000000000000 

0.000000000000000 

0.000000000000000 

0.000000000000000 

0.000000000000000 

0.000000000000000 

Current derivatives of function wrt shape design variables of body 2 
0.000000000000000 
0.000000000000000 

Global Design Variable Data This section of rubber. data lays out global 
design variables for the computation. These include the freestream Mach num- 
ber, angle of attack, and angle of yaw. For simulations using a noninertial ref- 
erence frame, the noninertial rotation rates about each of the three Cartesian 
coordinate axes are also available as design variables. 

Quantities associated with each variable are specified on their own row 
in the hie and have several attributes that must be set by the user. The first 
column is a dummy index and is merely to assist the user in quickly navigating 
through the hie. The second column is a toggle to activate the design variable. 
If this value is a 1, the variable will be allowed to change during the design. 
If the value is assigned a 0, this variable will be held constant at the value 
specihed. For incompressible hows and mixed-element grids, the Mach number 
must be declared inactive. Similarly, for hows posed in the inertial reference 
frame, the noninertial rates must be declared inactive. 

The third column in the design variable block is the current value for 
this design variable. The values of any active variables in this hie will take 
precedence over other input decks during design. For example, the how solver 
will run an angle of attack of 1 degree in this case, regardless of what may be 
specihed in fun3d.nml. Columns four and hve specify the upper and lower 
bounds for the current design variable. 

Body-Specific Design Variable Data The next input following the Mach 
number and angle of attack entries specifies the number of bodies for which 
the user has provided shape parameterizations. Note that not every body in 
the grid must be included here. If the wing of an aircraft is the sole focus of 
the optimization, there is no need to account for other boundaries such as the 
tail or fuselage here. 

Following the number of bodies, there should be two blocks of design vari- 
ables for each desired body, namely a list of rigid motion variables controlling 
the dynamics of the body, and a set of shape parameters controlling the shape 
of the body. The columns of inputs are identical to those described above for 
Mach number and angle of attack. 

The bodies present in the computation may be listed in any order; how- 
ever, the order of their appearance in this control file must match the integer 
suffix on their parameterization files that are provided in the description.! 
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directory, as well as files such as body -grouping, data, transf orms.j, etc. 

The first section for the current body specifies design variables governing 
rigid body motion and is only applicable for time-dependent problems. For 
optimization of steady flows and/or static geometries, the rigid motion data 
is irrelevant but must be present in this file. These variables should be set as 
inactive in these cases. 

The next block of inputs relates to the shape parameterization for the 
current body. First, the parameterization scheme is identified by a scalar 
integer. The following values are available: (1) MASSOUD, (2) Bandaids, 
(4) Sculptor M , and (5) User-Defined. The next input specifies the number of 
parameterized shape variables on the current body and the subsequent lines 
lay out the design variable information for that body. A row of data must 
be provided for every variable in the parameterization, whether it is active 
or not. (Note however, that internally, the optimizer is only made aware of 
the variables marked as active.) If a parameterization contains 25 variables, 
then 25 rows must appear in this corresponding block of rubber. data, even if 
only a subset is active. If the design variable linking feature in MASSOUD or 
Bandaids has been used to create additional derived variables, they must also 
appear here. Note that the “Active” attribute for shape variables may take 
values of not only 0 or 1, but also —1 in certain multi-point design scenarios 
(see section 9.10). 

Care should be taken in choosing upper and lower bounds for shape vari- 
ables. Optimizers tend to fully explore the design space, which may result in 
infeasible shapes (or extreme shapes the mesh movement /solvers cannot han- 
dle robustly). Set these limits conservatively; one can always restart a design 
with less restrictive bounds. 

As noted previously, when using Sculptor M parameterizations for multiple 
bodies, all such design variables must appear as a single concatenated body in 

rubber . data. 

Cost Function/Constraint Specification The first line following the de- 
sign variable block specifies the total number of composite functions to be used 
as objectives or constraints for the current design point. Multiple composite 
objective functions may be specified in certain cases; see section 9.9. Other- 
wise, a single composite objective function must be specified. The example 
file shown here contains a single composite objective function based on the 
lift coefficient and a single explicit constraint based on the pitching moment. 
Note that explicit constraints may only be specified if the optimization package 
chosen in the fedesign namelist in design. nml supports them. 

Following the scalar value specifying the total number of composite objec- 
tives and constraints, each composite function and/or constraint will have a 
block of data associated with it. Objective functions and constraints may be 
specified in any order. 
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The first two inputs in the composite function block specify a scalar integer 
indicating how the current function is to be viewed by the optimizer. The two 
subsequent inputs represent lower and upper bounds on the function if it is 
to be used as a constraint. If the function is an objective function, the first 
input value should be 1, and the lower and upper bounds must be present but 
their values are irrelevant. However, if the current function is to be used as 
a constraint, special attention must be paid to these inputs depending on the 
optimization package being used. 

Constraints Using NPSOL™ and SNOPT™ If the current function 
is to be used as an inequality constraint, the first input should be 2, and 
the lower and upper bounds should be set to their appropriate values. If the 
current function is to be used as an equality constraint, the first input should 
be 2; however, the lower and upper bounds should both be set equal to the 
desired constraint value. 

Constraints Using KSOPT and DOT/BIGDOT™ These optimiza- 
tion packages assume constraint functions of the form / < 0, such that the 
bound of the feasibility region is implicit in the function definition and the 
lower and upper bound inputs must be present but are not used. If the cur- 
rent function is intended as an inequality constraint, the first input should be 
2. If the current function is intended as an equality constraint, the first input 
value should be 3. In this case, Fun3D’s design driver will provide the current 
function to the optimizer as an inequality constraint, but will also bookkeep 
an equal and opposite function as an additional inequality constraint. In this 
manner, an equality constraint is achieved by only allowing the intersection of 
the two inequality constraints as feasible. 

Following the classification of the current function, the next line states how 
many component functions comprise the current composite function. This can 
be any positive integer greater than or equal to 1. Following the number of 
component functions, the user must specify the physical time step interval over 
which the function is to be applied. This input is only relevant to optimization 
of unsteady flows. For steady flows, the values of these two inputs are ignored 
but must be present. 

The weight, target, and power to be applied to the current composite 
function are specified next. These values are only relevant when combining 
multiple composite objective functions into a single global objective function 
(see section 9.9). For all other cases, these values should be specified as 1.0, 
0.0, and 1.0, respectively. 

At this point, each component function that contributes to the current 
composite function has a line specifying several pieces of data. The first col- 
umn is the boundary patch over which to apply the current component. This 
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index corresponds directly to the boundary patches in the CFD grid, and 
must reflect any patch lumping that is indicated in the &raw_grid namelist 
in fun3d.nml (see section B.4.2). If a component function is to be used over 
the entire grid (total drag, for example), simply put a 0 in this column. Al- 
ternatively, if a single boundary patch is to be targeted, one might apply the 
component function to only that patch. Several patches may be targeted by 
including a component function for each. The next column is the keyword for 
the aerodynamic quantity to be used for the current function component. For 
a list of available keywords, see section 9.1. The next column contains the cur- 
rent value of the current function component. This is an output value during 
the optimization and need not be set by the user. The final three columns in 
the row correspond to the weight, target value, and power to be applied to the 
current component function in constructing the overall composite function. 

Current Function Value and Sensitivities Following the specification of 
the component functions, the next line of rubber. data contains the current 
value of the composite function. This is an output and need not be set by the 
user. 

The remaining lines in the current function block contain the sensitivity 
derivatives with respect to all of the design variables listed in the top half of the 
file. This section is divided into derivatives with respect to the global design 
variables, as well as the rigid motion and shape design variables for each of the 
bodies laid out in the top portion of the file. These derivatives are outputs set 
by Fun3D and not by the user. However, a line for each design variable (both 
global variables as well as body-specific variables) must be provided in each 
composite function block present. The values do not matter, but the solvers 
need positions available in the file to store the current values. 

9.6.3 ae_target.dat (optional) 

If the function keyword ae is specified anywhere in rubber. data, the file 
ae_target.dat must be present prior to performing the optimization. This file 
provides the target equivalent area distribution(s) for each of the azimuthal 
locations specified in the &equivalent_area namelist in fun3d.nml (in the 
same order). See section 9.2.8 and section B.4.37. 

9.6.4 body .grouping, data (optional) 

This file is used to specify body grouping information. For example, if the 
objective function is the Figure of Merit FM for a three-bladed rotor, then 
the three blades (each typically specified as a separate parameterized body in 
rubber. data) should be associated into one group, so that sensitivity deriva- 
tives will reflect a composite d(FM)/dD for all three blades. This capability 
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requires that the bodies to be associated all have identical parameterizations 
(same number of design variables on each body, etc). The format of the 
body .grouping. data hie is as follows: 

Number of groups to create 
1 

Number of bodies in group, list of bodies 
3 

1 2 3 


The first scalar integer specifies the number of groups to create (i.e. , one rotor). 
The next set of inputs specifies the number of bodies in each group, followed 
by the bodies that comprise that group (i.e., each of the three rotor blade 
bodies). 

9.6.5 command line . options (optional) 

The command.line . options hie specihes any command line options to be used 
with the how solver, the adjoint solver, or the MPI job launcher (mpirun, 
mpiexec, aprun, etc). An example of this hie is shown below. 

3 

1 flow 

' — rmstol l.e-7 1 

1 adjoint 

' — rmstol l.e-3' 

2 mpirun 

' -nolocal ' 

' -machinef ile . . /machinef ile ' 

The hrst line of the hie specihes the number of programs for which command 
line options are being provided. The subsequent line must contain an integer 
followed by a keyword. The integer specihes how many command line options 
are being provided for the code identified by the keyword. The valid keywords 
are flow, adjoint, and mpirun. This line is followed by a line for each of the 
command line options provided for the code identihed by the keyword. Each 
command line option should appear in single quotation marks on its own line. 
The specihed programs and their associated command line options may appear 
in any order. 

If a -np x option is provided as a command line option to the MPI job 
launcher to specify the number of processes to run (given by the value x), this 
value will override the value specihed for execution of the adjoint solver in the 
&design namelist in design. nml (see section 9.5.1). 
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9.6.6 cpstar.data. j (optional) 

Fun3D has an inverse design capability where the objective function may 
be composed of target pressure distributions. The hie containing the jth 
target distribution must be named cpstar.data.j. However, setup is te- 
dious, primarily due to the difficulty in specifying pressure distributions on 
a three-dimensional configuration. If this capability is of interest, please con- 
tact Fun3D-Support@lists.nasa.gov for more detailed guidance. 

9.6.7 f iles_to_save .data (optional) 

If desired, users may indicate specific hies produced by the how and adjoint 
solvers to be archived during an optimization. For example, custom visual- 
ization hies may be produced at each design iteration (see section 5.3.1) to 
enable animations of the design history after the optimization is complete. 

To specify certain hies to be archived during the course of a design ex- 
ecution, the user may provide the optional hie f iles_to_save.data in the 
description.! directory. Each line of the hie consists of one of two key- 
words, either “Flow” or “Adjoint”, followed by the specihc name of a hie to 
be archived. For example, the following inputs could be used to archive Tec- 
plot™ hies containing solution data on boundaries for both the how and adjoint 
solvers, while also saving two additional Tecplot™ hies containing user-specihed 
sampling data for the how solution: 

Flow [pro j ect_rootname] _tec_boundary . dat 
Flow [pro j ect_rootname] _tec_sampling_geoml . dat 
Flow [pro j ect_rootname] _tec_sampling_geom2 . dat 
Adjoint [pro j ect_rootname] _tec_boundary . dat 

At the end of each function evaluation (i.e. , how solution) for the ith design 
point, the hies [project_rootnamej_tec_boundary.dat, [project_rootname] 
_tec_sampling_geoml.dat, and [project_rootname] _tec_sampling_geom2.dat 
will be stored in the model. i/Flow/SaveFiles directory, with an integer cor- 
responding to the current design iteration appended to each of the filenames. 
Similarly, the hie [projectxrootname] _tec_boundary.dat will be stored in the 
model. i/Adjoint/SaveFiles directory at the completion of each sensitivity 
analysis (i.e., adjoint solution). 

9.6.8 machinefile (optional) 

If the optimization will be executed in an environment which requires an ex- 
plicit list of machines on which the MPI jobs will be executed, this hie must 
be present. It should take the format required of the particular MPI imple- 
mentation being used. If the optimization will be executed in an automated 
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queuing environment, the job scheduler normally assigns the machines to be 
used at runtime and this hie is therefore not required. 

9.6.9 pressure_target.dat (optional) 

If the function keyword boomvtarg is specified anywhere in rubber. data, the 
hie pressure_target.dat must be present prior to performing the optimiza- 
tion. This hie provides the nearheld target p/poo distribution (s) for each of 
the off-body locations specihed in the &sonic_boom namelist in fun3d.nral (in 
the same order). See section 9.2.6 and section B.4.35. 

9.6.10 transforms.! (optional) 

Since MASSOUD uses a coordinate system specihc to an assumed aircraft 
orientation, it is sometimes necessary to reorient a body from its physical 
position to a MASSOUD-aligned coordinate system and vice-versa. Examples 
might include a vertical tail or the various blades of a rotor system. The hie 
describing the transform for the ith body should be included as transforms.!. 
The format of a typical transforms.! hie is as follows: 

ROTATE 0.0 0.0 1.0 -120.0 

This would rotate the MASSOUD parameterization for the ith body by —120 
degrees about a unit vector in the +z direction. The commands TRANSLATE 
and SCALE are also available. 

9.7 Contents of the model, i Directory 

Just as for the description, i directories, the i in the model . i naming con- 
vention represents the design point index. This value is 1 for single point design 
or the design point index for multi-point design. The model . i directory con- 
tains the subdirectories Flow, Adjoint, and Rubberize. During the course 
of the design procedure, Fun3D will evaluate the relevant parameterizations 
and perform how and adjoint solutions within these locations. These sub- 
directories are populated during the initial setup procedure with links to the 
required executables from the user’s Fun3D installation. Files in the model . i 
subdirectories should not be modified by the user, although one may wish to 
observe various solver output hies during the course of the optimization. All 
user-provided inputs are confined to hies located in the description.! and 
ammo directories. 

9.8 Running the Optimization 

Once all of the required inputs and hies have been provided, the user should 
hrst request a single function evaluation from the optimization driver. This is 
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strongly recommended in order to identify any potential issues in the various 
inputs. To perform this check, set the value of what_to_do in the &design 
namelist in design. nml to 1, and execute the optimization driver from the 
ammo subdirectory: 

opt_driver > screen. output & 

Here, the output from the optimization driver has been redirected to a hie 
called screen, output. This hie is very useful if a problem needs to be diag- 
nosed with the execution. It is also good practice to include this hie with help 
requests to Fun3D-Support@lists.nasa.gov. 

At the completion of the function evaluation, the user should check for the 
desired/expected result. This is also a good opportunity to establish reason- 
able values for the number of time steps to run, the residual tolerance at which 
the solver should quit, and so forth. Such run control parameters may be set 
in fun3d.nml or via the command.line . options hie. 

Once the function evaluation procedure has been verihed, the user should 
perform the same test for a sensitivity analysis by setting what_to_do in the 
&design namelist in design. nml to 2 and re-executing the optimization driver. 
Similar checks on convergence parameters, etc for the adjoint solver should be 
noted and applied to the relevant input hies. 

With successful function and gradient evaluations in hand, an actual opti- 
mization may be initiated. The value of what_to_do in the fedesign namelist in 
design. nml should be set to 3, and the optimization driver can be executed as 
before. The user should closely monitor the screen output as the process pro- 
ceeds, especially during the hrst several design cycles when input parameters 
may hrst cause problems. The largest changes in design variables often occur 
early on as well, which can cause issues with mesh movement operations, solver 
convergence, and other aspects. It is also very useful to occasionally hlter the 
screen output for the current function value (s) reported at the completion of 
each how solution in order to monitor overall progress: 

grep "Current value of function" screen . output 

When an optimization completes, the optimizer will report the reason for 
the termination to the screen, which may be a local minimum, or some prob- 
lem encountered during the simulation. A summary of the optimization is 
provided by each optimization package in the hle(s) noted in Table 12. The 
hnal set of design variables and function/constraint values determined by the 
optimizer will be available in model. i/rubber. data. To track the history of the 
optimization, a backup of all intermediate copies of rubber. data are stored 
in the directory model. i/Rubberize/surf ace_history. Intermediate copies 
of the surface grids developed during the design process are also stored in this 
location as model. tec. j .sdl. iter, where j is the body index, and iter is the 
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design iteration. These files may be used to produce animations of the surface 
history if desired. Using the broad range of visualization output options for 
the solvers, the user has great freedom to produce customized animations of 
the design history (see section 9.6.7). 


Table 12: Files containing design summary from various optimization packages. 
Optimization Package Summary File(s) 


DOT/BIGDOT™ 

KSOPT 

PORT 

NPSOL™ 

SNOPT™ 


dot. output 
ksopt. output 
port. output 

npsol.printfile, npsol.summaryfile 
snopt.printfile, snopt.su mmaryfile 


9.8.1 Filesystem Latency Problems 

Design optimization using some cached hie systems may experience problems 
due to the rapid execution of the various tools during the design process. In 
some cases, a hie system lag may cause some processes to receive older/stale 
versions of hies during execution. Specifying the — sleep_delay [seconds] 
command line option to the opt_driver executable will pause the optimization 
process with a sleep duration of seconds between subsequent code executions 
to allow the hie system to perform correctly. On older systems, delays as large 
as 60 seconds are sometimes necessary; more recent systems seem to perform 
considerably better and values of 5-10 seconds are often sufficient. 

9.9 Multi-objective Design 

KSOPT, PORT, and SNOPT M are the only packages currently supported for 
use with multi-objective design. Details on the usage for each package are 
provided below. 

9.9.1 KSOPT 

KSOPT is the only supported optimization package with explicit support for 
multiple objective functions. When using KSOPT, the user may designate any 
number of composite functions as objective functions in rubber. data. 

9.9.2 PORT, SNOPT™ 

The Fun3D design driver offers a simple approach to scalarizing multiple user- 
specified objective functions for use with the PORT or SNOPT M packages. If 
multiple composite functions are specihed in rubber. data, the Fun3D design 
driver will combine them using the weight, target, and power values specihed 


at the composite function level (i.e. , the input values that appear just before 
the component function data is specified in rubber. data, see section 9.6.2). If 
N composite functions / are labeled as objective functions in rubber. data, the 
scalarized objective function F to be provided to the optimization procedure 
will take the form 

f = ai(/i - nr + « 2 (/ 2 - nr + ... + mjn - /;r (12) 

where cq, /*, and p t are the weight, target, and power values associated with 
each composite function in rubber. data. 

9.10 Multi-point Design 

The Fun 3D design infrastructure offers several approaches to multi-point op- 
timization. This refers to design problems where the user may wish to simul- 
taneously optimize a configuration for operations at two different conditions 
- perhaps the beginning and end of a cruise segment for example, where the 
aircraft weight may be substantially different. The user may also wish to de- 
sign for cruise and takeoff or landing (or all three). The various design points 
may be characterized by different flow conditions (i.e., speed, angle of attack, 
etc), or more generally, by the geometries (and therefore grids) at each point. 
For example, one design point may consist of a cruise geometry operating at 
Mach 0.8, while another design point may be a landing configuration operating 
at Mach 0.2 with a high-lift system deployed. For examples of FuN3D-based 
multi-point design in practice, see the studies in [13] and [21]. In these ref- 
erences, a tilt-rotor geometry has been optimized for a set of several blade 
collective settings as well as hover and forward flight conditions. 

To perform a multi-point optimization, the user must request the desired 
number of design points when setting up the directory structure where the 
design will be performed (see section 9.4). The user must populate each of 
the description.! directories for each design point i just as in the single- 
point design context. The order of the design points does not matter. The 
value of n_design_pts in the fedesign namelist in design. nral should be set 
appropriately. Ultimately, Fun 3D provides several ways to formulate the 
multi-point design problem. These approaches are outlined below. 

In general, the optimizer will be seeking a unique set of design variables 
to simultaneously achieve goals at all of the design points. For this reason, a 
consistent set of design variables across all design points must be used. This 
applies to the global variables Mach number and angle of attack as well as any 
body-specific variables such as shape parameters. For example, if a set of 15 
thickness variables is provided for a wing shape in cruise, other design points 
(again, perhaps a landing configuration as an example) must utilize the same 
set of 15 thickness variables. Moreover, the same subset of design variables 
must be active at each design point. 
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Multi-valued Design Variables In some situations, the user may desire 
different optimal values of a design variable at different design points. For 
example, consider power minimization for a rotor in hover at two different 
weight conditions, where each of the two design points may have different 
minimum thrust coefficients posed as constraints. In addition to other design 
variables that may be present, the user may have a shape parameter controlling 
the blade collective setting (blade pitch). However, rather than constraining 
the optimal blade collective to a single unique value, the user may desire 
separate, optimal values for each design point. As another example, consider 
a configuration with an ability to actively morph its outer mold line. In this 
case, the user may wish to determine optimal values of the shape parameters 
that are unique to different design points. 

To accommodate such multi-valued design variables, the user may set the 
“Active” attribute for individual shape design variables to —1 in rubber. data 
(see section 9.6.2). If this is done, it must be applied consistently for that 
same variable across all design points. For variables with this attribute, the 
Fun 3 D design driver will internally bookkeep separate values of the variable 
for each design point. This feature is currently only available for use with the 
SNOPT™ package. 

9.10.1 Linear Combination of Objective Functions 

The most straightforward approach to multi-point design is to linearly combine 
individual objective functions fi from each of the N design points i into a single 
global objective function f mp \ 

fmp = cnifi + 02/2 + 0^3/3 + ••• + <^nJn ( 13 ) 

To perform the optimization in this fashion, a single composite objective func- 
tion should be posed in each description. i/rubber. data file. Each of the cq 
weighting coefficients must be specified in the design_pt_weight ( : ) array in 
the fedesign namelist in design. nml, in the corresponding order. 

This form of multi-point design is supported by PORT, DOT/BIGDOT M , 
and SNOPT M . Note that PORT and SNOPT M will also combine multiple 
objective functions within each design point as described in section 9.9 if de- 
sired. Explicit constraints can be posed at each design point when using 
DOT/BIGDOT M or SNOPT M ; such constraints are each treated individually. 

9.10.2 Combination of Objective Functions using the Kreisselmeier- 
Steinhauser Function 

Another alternative for performing multi-point design is the approach inher- 
ent in the KSOPT package. In this approach, all objective functions and 
constraints are combined using the Kreisselmeier-Steinhauser (KS) function. 


The user is referred to [22] for the details of this formulation. Here, the Fun3D 
design driver gathers any number of objective and constraint functions across 
all design points and provides them to KSOPT, which internally constructs 
its KS function for the actual optimization problem. 

9.10.3 Single-Point Objective Function with Off-Design Constraint 
Functions 

In this approach to multi-point design, a single objective function is provided 
to the optimizer, while all other functions are treated as explicit constraints. 
Here, the user should designate a single composite function across all of the 
description. i/rubber. data input files as an objective function. Any other 
composite functions at each design point should be designated as constraint 
functions. KSOPT, SNOPT™, and NPSOL M support this form of multi-point 
optimization; SNOPT M can also construct the final objective function by lin- 
early combining multiple objective functions within the desired design point 
as described in section 9.9. 

9.11 Optimization of Two-Dimensional Geometries 

While the Fun 3D flow solver supports a 2D mode of operation, this capability 
is not currently available from within the design infrastructure. Instead, the 
optimization must be performed as a pseudo-3D case. The user should pro- 
vide a nominally two-dimensional grid, with a single layer of elements in the 
spanwise (y) direction. The mesh should consist of either prisms or hexahedra 
(or both), but should contain no pyramids or tetrahedra. Follow the same 
procedure used for 3D cases to extract the surface grid for parameterization. 
The surface should be parameterized just as for a 3D simulation; however, the 
parameterization should allow no spanwise asymmetries in the geometry to 
develop. When using MASSOUD or Bandaids, this is readily accomplished 
by linking the raw parameters with an equal weighting across the span into a 
single set of design variables that operate in a chordwise fashion. Note that 
the sidewalls should use symmetry _y boundary conditions so that only in-plane 
mesh deformation occurs during the optimization. The design may now be ex- 
ecuted as usual, with the 2D nature of the problem enforced implicitly through 
the parameterization. 

9.12 Using a Different Optimization Package 

In a CFD-based design context, the term “function” implies an evaluation of 
the geometric parameterization, mesh movement (both surface and volume), 
a flow solution, and an evaluation of the output function/constraint for a 
given set of design variables. The file manipulations and solver operations 


necessary to achieve this are not trivial. For users interested in using the 
tools as “black boxes” providing function data for an optimization package, a 
wrapper has been provided in the LibF90 directory of the distribution named 
analysis.f 90. This module contains a subroutine called perf orra_analysis () 
which performs the extensive set of tasks involved with producing the final 
desired function output. 

To obtain sensitivities, the Fun 3D package relies on a discrete adjoint for- 
mulation. As with function evaluations, the low-level operations required to 
perform an adjoint-based sensitivity analysis are numerous. A wrapper routine 
called perf orm_sensitivity_analysis () in the LibF90/sensitivity.f90 
module will perform an adjoint solution for the flow field, an adjoint solu- 
tion for the mesh movement scheme, an evaluation of the linearized geometric 
parameterization, and finally produce the desired sensitivity derivatives. 

The Fun3D design driver uses the wrappers perf orra_analysis () and 
perf orm_sensitivity_analysis () to greatly simplify function and gradient 
evaluations when connecting to off-the-shelf optimization packages. If the 
user wishes to implement a new optimization strategy, it is highly recom- 
mended that these wrappers be used in a similar fashion. A review of the 
existing modules in the Design directory of the Fun3D source code distribu- 
tion, which implement the currently available optimization interfaces, is also 
strongly suggested. Users may contact Fun3D-Support@lists.nasa.gov for 
further guidance in leveraging Fun3D’s capabilities from within their own 
existing design framework. 

9.13 Implementing New Cost Functions/Constraints 

Implementation of new cost functions or constraints is not a trivial undertak- 
ing and requires extensive modification of Fun 3D source code. Experience 
in Fortran 2003, unstructured-grid discretizations, development in a domain- 
decomposed/distributed-memory environment, and general CFD methods are 
essential. Routines to evaluate the proposed function and linearizations of the 
function with respect to both the flow held variables and grid are ultimately 
required. The complex- variable form of Fun 3D (see section 9.14) is invalu- 
able in verifying the accuracy of these linearizations. It is highly recommended 
that the user contact Fun3D-Support@lists.nasa.gov for guidance prior to 
attempting the implementation of a new cost function or constraint. 

9.14 Forward Mode Differentiation Using Complex 
Variables 

The reverse, or adjoint, mode of differentiation is primarily used for design 
with Fun 3D. A forward mode of differentiation is also provided based on the 
use of complex variables [23-25]. This capability is useful for design problems 
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containing few design variables and many cost functions or constraints. To 
generate and build a complex-variable Fun 3D executable, see section A. 5. 

The complex- valued flow solver reads the usual real- valued grid hies and is 
set up to compute derivatives of every output variable with respect to Mach 
number, angle of attack, shape parameters, non-inertial rotation rates, or the 
x, y, or z coordinate of a single grid point (others are trivial to add). This 
choice is controlled by the hie perturb. input. A template for this hie is 
provided in the FUN3D_90 directory and an example is also shown below. 

PERTURB EPSILON GRIDPOINT 

2 l.e-50 666 

0 = No perturbation 

1 = Mach number 

2 = Alpha 

3 = Shape 

4 = x-rotation rate 

5 = y-rotation rate 

6 = z-rotation rate 

7 = Grid point x 

8 = Grid point y 

9 = Grid point z 

10 = Yaw 

100+ = add an imaginary source term to equation 
PERTURB- 100 of node GRIDPOINT 
(to verify the adjoint lambda value) 


The value of PERTURB specihes the variable for which sensitivities will be 
taken with respect to. The valid integer values are as shown above. The input 
EPSILON specihes the magnitude of the imaginary perturbation to be applied. 
The recommended value is l.e-50. If the value of PERTURB is greater than 
six, the value of GRIDPOINT specihes the grid point index to perturb. The 
remaining lines in perturb. input are not read; they are simply reminders of 
the valid inputs just described. The complex- valued how solver may then be 
executed in a manner similar to the real- valued how solver: 

mpirun . /complex_nodet_mpi 

To compute derivatives with respect to a shape parameterization variable, the 
sensitivities of the parameterization must hrst be evaluated in the directory 
model . i/Rubberize using the relevant parameterization software. The value 
of PERTURB should be set to 3 in perturb . input. The complex-valued how 
solver can then be executed in the following fashion: 
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mpirun . /complex_nodet_mpi — dv_index [body] [dv] — snap_grid 


Here, the values of body and dv specify the body and design variable index in 
rubber . data to which to apply the imaginary perturbation. The — snap.grid 
argument forces the flow solver to propagate the surface sensitivities into the 
volume mesh using Fun3D’s elasticity-based deformation mechanics. 

At the completion of the complex-valued flow solve, outputs will contain 
both real and imaginary parts. The imaginary part represents the sensitivity 
of that output with respect to the perturbation variable that was specified in 
perturb . input. 
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Appendix A 


Installation 


Fun3D is distributed as gzipped archive of source code. The GNU build 
system is used to package and install Fun3D. The required installation steps 
are detailed in this section. Due to the large range of capabilities, configuring 
the dependent packages is the most involved step and is the focus this section. 
As was illustrated in the Quick Start section, four basic steps are required: 

1. Extract the source code from the gzipped tarball archive with tar 

2. Configure the desired dependencies and compiler options with conf igure 

3. Compile via make 

4. Install the compiled binaries and supporting scripts via make install 

If any difficulties arise with the installation process please, send the entire 
conf ig. log hie produced by configure and the full stdout and stderr of make 
to Fun3D-Support@lists.nasa.gov. The user is strongly advised against 
editing the configure script or any Makefile it produces. We are unable to 
assist users who have edited these hies. 

A.l Extracting Files 

After downloading the source code as a gzipped tarball, the user can unpack 
it with 

tar zxf fun3d-12 . 8-* . tar .gz 

which will create the directory fun3d-12 . 8-*. (The * represents a code that 
the Fun3D uses internally to version the code.) If you have do not have a 
GNU-compatible tar, you may have to insert a separate decompression step, 
i.e., 


gzip -d fun3d-12 . 8-* . tar .gz | tar zxf - 

A. 2 Configure Introduction 

The Fun 3D suite of tools is configured and built via the GNU build system 
and must be configured hrst. Change to this directory, e.g., cd fun3d-12 . 8-*, 
and execute 

./configure — help 
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to see a list of all available compilation options. When configure is invoked, 
detailed results of all the tests it performs are written to the hie conf ig. log. 
Some features of the configure step that have caused problems for users 

are: 

• An incorrect spelling of a --enable-* or — with-* option is silently 
ignored. This will result in the intended option not being included in 
the compiled executable. 

• Option values containing spaces must be quoted to be correctly inter- 
preted by the shell (i.e. , FCFLAGS=’ -optionl -option2’). 

• If the configure command is executed more than once with different 
options, make clean is required before the make step, so that changes 
to the configuration are correctly reflected in the compiled executable. 

A. 3 Alternative Installation Path 

The path to the installation directory is specified by the — prefix= option. 
The default is to install to /usr/local with executables placed in /usr/ 
local/bin. This default location may not be available if the user does not have 
write permission to this directory (without root or administrator privileges). 

To install to an alternative path (e.g., $H0ME/local), use the — prefix= 
option to set the installation path 

./configure — pref ix=$HOME/local 

Finally, to include the Fun 3D executables in the command search path, add 
setenv PATH $HOME/local/bin: $PATH 
to the ~/.cshrc hie or the equivalent for your shell. 

A. 4 Fortran Compiler Option Tuning (FTune) 

By default, configure will use compiler and linker options chosen by the 
Fun 3D team. The process is referred to as “FTune.” The users PATH is 
searched in a predefined order until the first FuN3D-compatiblc compiler is 
found. When configured with MPI, the build will use mpif90 located in the 
bin directory of the given MPI installation^ 1 However, the user can explicitly 
specify the desired Fortran compiler via the FC environment variable. 

To directly specify the compiler and linker options, use the FCFLAGS and 
LDFLAGS environment variables. The default behavior is to append their values 
to the options defined by FTune. If the — disable-ftune option is given 
to configure, FTune will be disabled and the values given by FCFLAGS and 

A1 To see what the underlying compiler is, use mpif90 -show. 
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LDFLAGS will be used explicitly. For example, to ensure that the Intel® Fortran 
compiler ifort is used with only the -03, -ip, and -Ira options, 

./configure — disable-f tune \ 

FC=ifort \ 

FCFLAGS= ' -03 -ip' \ 

LDFLAGS= ' -lm ' 

The order of variables and options are inconsequential, and single quotation 
marks ( ’ ) are used to protect values with spaces from the shell. Some FTune 
options may be unconditionally required for a given compiler, as in the case of 
linking with the math library -Ira above. 

A. 5 Complex Variable Version 

The Fun 3D suite can be compiled with the real variables in the code re- 
placed with complex variables by a source translation tool. This permits 
the computation of forward-mode sensitivities, see section 9.14 for details. 
To enable, add the --enable- complex configure option to the configure 
script. The complex-valued code can be compiled with make complex; and a 
make install will place the complex-valued executables in the bin installa- 
tion directory. Enabling the complex variable version will increase the compile 
time. 

A. 6 Internal Libraries 

Fun 3D has internal dependencies to libraries that are distributed with Fun 3D. 
These libraries are automatically built and linked to Fun 3D by default. 

A. 6.1 KNIFE 

The KNIFE cutcell library provides cutccll capabilities. The --without-knif e 
option will disable this library. 

A. 6. 2 REFINE 

The refine library provides access mesh adaptation and untangling capabil- 
ities. The --without-ref ine option will disable this library. 

A. 7 External Libraries 

Fun 3D relies on external libraries to enable some of its advanced applications. 
Use Table Al to determine which set of external libraries are necessary for your 
applications of interest. Discussions of each external library are found in the 
following sections. 
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Table Al: Configuration options. 
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It is highly recommended that Fun 3D is configured to use a parallel ex- 
ecution (MPI and one of the partitioner libraries) if you plan to perform any 
advanced calculations. SUGGAR++ and DiRTlib are only required if over- 
set (chimera) meshes will be used. The 6-DOF library is only required if six 
degrees of freedom simulations will be performed (trajectories determined by 
integrating the equation of motion). KSOPT, PORT, SNOPT™, NPSOL™, 
and DOT/BIGDOT M are optimization libraries. At least one of these opti- 
mization libraries is required for performing design optimization. 

A. 7.1 MPI 

MPI provides Fun3D’s capability to communicate between processors. Con- 
figure with the option 

— with-mpi=/path/to/MPI 

where /path/to/MPI is the directory where MPI is installed. 

In addition, Fun 3D must be executed in an environment that repre- 
sents the same MPI installation used for configuration/compilation (e.g. same 
mpiexec, mpirun, etc.). Failure to provide such consistency will result in un- 
defined behavior and undetermined segmentation faults. 
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In some cases, MPI may already be installed on the target machine. If it is 
not, OpenMPI or MPICH can be used and the option of static MPI libraries 
is recommended. Also, if building OpenMPI or MPICH from source, it is 
important to maintain consistency with compilers (both vendor and version) 
throughout the build and execution of Fun3D and its dependent libraries. 
For example, if OpenMPI is built with gfortran version 4.4.7, then the ex- 
ecution environment for Fun3D must reflect the same vendor and version, 
gfortran 4.4.7. Fun3D execution must also employ the same mpiexec from 
the OpenMPI installation used to build the software. 

Some high performance computing environments use a proprietary MPI 
implementation that does not provide mpif90. It that situation, the config- 
ure option — without -mpif 90 may be required in combination with the FC 
environment variable to explicitly set the compiler. 


Verifying the MPI Implementation Functionality A simple Fortran 
program is included in the FUN3D distribution to verify that the MPI imple- 
mentation is functional. This is very helpful for quickly troubleshooting issues 
with the MPI implementation. It is located in utils/MPIcheck. From within 
that directory you should be able to 

mpif 90 -o mpi_hello_world mpi_hello_world.F90 

and execute on two processors 

mpiexec -np 2 . /mpi_hello_world 

0 says, "Hello World!" 5=5 

1 says, "Hello World!" 5=5 

To verify the Fortran compiler that MPI is built with, try 
mpif90 -show 

if the MPI implementation supports it. 

A.7.2 ParMETIS 

Website: http : //glaros. dtc.umn.edu/gkhome/metis/parmetis/overview 
The ParMETIS library performs domain decomposition to enable parallel 
execution of Fun3D. It is critical that Fun3D and ParMETIS are compiled 
with exactly the same MPI installation and compilers. This includes the C 
compiler used to compile MPI, ParMETIS, and FUN3D. 

When configuring Fun 3D, use 

— with-parmetis=/path/to/ParMETIS 
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where /path/to/ParMETIS is the directory of the ParMETIS installation. 
Fun3D expects the /path/to/ParMETIS directory to contain the following 
hies in lib and include subdirectories, 

/path/to/ParMETIS/lib/libmetis . a 
/path/to/ParMETIS/lib/libparmetis . a 
/path/to/ParMETIS/ include/metis .h 
/path/to/ParMETIS/ include/parmetis . h 

These required libraries includes a version of the sequential execution tool 
METIS packaged with ParMETIS. This included version of METIS is required 
and must also be built. The included version is incompatible with the inde- 
pendently distributed METIS version. 

See the Install.txt instructions in the ParMETIS distribution for build 
instructions. Fun3D requires both libmetis.a and libparmetis.a libraries 
and their accompanying header hies. There is an example of commands to 
build both libraries, 

cd parmetis-4.* 

make config pref ix=/path/to/ParMETIS 
make install 
cd metis 

make config pref ix=/path/to/ParMETIS 
make install 

where /path/to/ParMETIS matches the Fun 3D conhgure argument. 

A. 7. 3 Zoltan 

Website: http : //www. cs.sandia.gov/Zoltan/ 

The Zoltan library [26] performs domain decomposition to enable parallel 
execution of Fun3D. Note: Fun3D and Zoltan must be compiled with ex- 
actly the same MPI installation and compilers. This includes the C/Fortran 
compilers used to compile MPI, Zoltan, and FUN3D. 

When configuring Fun 3D, use 

— with-zoltan=/path/to/Zoltan 

where /path/to/Zoltan is the directory of the Zoltan installation. Fun 3D 
expects the /path/to/Zoltan directory to contain the following hies in lib 
and include subdirectories, 

/path/to/Zoltan/lib/libzoltan. a 
/path/to/Zoltan/include/zoltan . h 
/path/to/Zoltan/include/zoltan .mod 
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The header file zoltan.h recursively includes a number of header files in the 
include path. 

See the User’s Guide on the Zoltan website for “Building the Zoltan Li- 
brary” instructions. The Autotools stand-alone build environment is recom- 
mended over the CMake option for use with Fun3D. To use Zoltan with 
Fun3D, the Zoltan library must be built with Fortran support. The same 
C/Fortran compilers and MPI implementation used for FUN3D should be in 
your path. Here is an example of configuring and building Zoltan for use with 
Fun3D, 

cd Zoltan_v3.* 
mkdir build 
cd build 
../configure \ 

— pref ix=/path/to/Zoltan \ 

— enable-mpi \ 

— with-mpi-compilers \ 

— enable-f 90interf ace \ 

— with-gnumake 
make everything 
make install 

While the Zoltan installation procedure supports builds against available ParMETlS 
installations, Fun3D does not require this. If the user wishes to use ParMETlS 
for domain decomposition, Fun3D should be built directly with ParMETlS 
support (see section A. 7. 2). 

A. 7. 4 SUGGAR++-1.0.10 or Higher 

Website: http : / / celeritassimtech.com 

SUGGAR++ is used for overset (chimera) applications and assembles com- 
posite meshes, cuts holes, determines interpolation coefficients, etc. If config- 
uring with SUGGAR++, Fun3D must also be configured with DiRTlib vl.40 
or higher. 

SUGGAR++ may be compiled as a stand-alone executable and/or as a li- 
brary. For static overset meshes you will need the stand-alone compilation; for 
moving body simulations you will need to compile both the stand-alone exe- 
cutable and the library. See the documentation that comes with SUGGAR++ 
for more information on how to compile the software. 

When configuring Fun 3D, use 

— with-suggar=/path/to/SUGGAR++ 

where /path/to/SUGGAR++ is the directory where SUGGAR++ library archive 
files (.a files) reside. In this directory, there must be an archive file called 
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libsuggar.a, which is the serial compilation of SUGGAR++, and there must 
also be an archive hie called libsuggar_mpi.a, which is the MPI compilation 
of SUGGAR++. 

A. 7. 5 DiRTlib vl.40 or higher 

Website: http : / / celeritassimtech.com 

The DiRTlib library must be linked to Fun3D in order to use the overset 
connectivity data computed by SUGGAR++-1.0.10 or Higher. See the docu- 
mentation that comes with DiRTlib for more information on how to compile 
the software. 

When configuring Fun 3D, use 
— with-dirtlib=/path/to/DiRTlib 

where /path/to/DiRTlib is the directory where DiRTlib library archive hies 
(.a hies) reside. In this directory, there must be an archive hie called libdirt.a, 
which is the serial compilation of DiRTlib, and there must also be an archive 
hie called libdirt_mpich.a, which is the MPI compilation of DiRTlib. 

A. 7.6 6-DOF 

Contact: Nathan.C.Prewitt@usace.army.mil 

The 6-DOF libraries provide trajectory tracing. When configuring Fun 3D, 
use 


— with-sixdof =/path/to/sixdof 

where /path/to/sixdof is the directory where your 6-DOF installation re- 
sides. 

A. 7.7 KSOPT 

Contact: Gregory.A.Wrenn@nasa.gov 

The KSOPT [22] library is used for multi-objective and constrained Fun 3D- 
based design optimization. If you configure Fun 3D to link to KSOPT, you 
must use the Fortran 90 implementation of KSOPT with its object hies gath- 
ered into a library called libksopt.a. 

When configuring Fun 3D, use 

— with-KSOPT=/path/to/ksopt 

where /path/to/ksopt is the directory where your KSOPT installation re- 
sides. 
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A.7.8 PORT 


Website: http : //www. netlib.org/port 

The PORT library is used for unconstrained FuN3D-based design opti- 
mization. The Netlib site offers a tarball of the PORT library with a Makefile. 
Download the tarball from Netlib, but replace the original Makefile with the 
hie included inside the Fun 3D distribution as Design/PORT. Makefile. If you 
install both the PORT and NPSOL M libraries, you may have to comment out 
low-level BLAS routines in one of the two packages because the linker will 
report the duplicate versions of these routines. 

When configuring Fun 3D, use 

— with-PORT=/path/to/port 

where /path/to/port is the directory where your PORT installation resides. 

A.7.9 SNOPT™ 

Website: http: //www.sbsi-sol-optimize.com 

The SNOPT M library is used for FuN3D-based design optimization. By 
default the SNOPT M package builds a shared library. Either build SNOPT M 
with the --disable-shared option, or add the the SNOPT M install directory 
to your LD_LIBRARY_PATH environment variable to ensure Fun3D can find the 
shared library at run time. 

When configuring Fun 3D, use 

— with-SNOPT=/path/to/ snopt 

where /path/to/ snopt is the directory where your SNOPT M installation re- 
sides. 

A.7.10 NPSOL™ 

Website: http: //www.sbsi-sol-optimize.com 

The NPSOL M library is used for constrained FUN3D-based design opti- 
mization. If you install both the PORT and NPSOL M libraries, you may have 
to comment out low-level BLAS routines in one of the two packages because 
the linker will report the duplicate versions of these routines. 

When configuring Fun 3D, use 

— with-NPSOL=/path/to/npsol 

where /path/to/npsol is the directory where your NPSOL M installation re- 
sides. 


109 


A.7.11 DOT/BIGDOT™ 


Website: http : //www. vrand.com/products.html 

The DOT/BIGDOT M library is used for unconstrained or constrained 
FUN3D-based design optimization. When configuring Fun 3D, use 

— with-DOT=/path/to/dot 

where /path/to/dot is the directory where your DOT/BIGDOT M installation 
resides. 

A.7.12 Tecplot™ 

Website: http://www.tecplot.com 

By default, any Tecplot™ output generated from within the flow solver itself 
is written as a text hie. If you have a copy of Tecplot™, you were provided 
with a library archive tecio.a (or tecio64.a for 64-bit versions) that allows 
for binary output. A2 You may configure the Fun3D suite to use the library 
via: 


— with-tecio=/path/to/tecio 

With this option, Tecplot™ solution data written out from the how solver will 
be in binary form. This results in smaller hie sizes and faster importation into 
Tecplot™. 

If you have compiled against the Tecplot™ tecio library, you can still 
request text output via the --ascii_tecplot_output command line option. 

A. 7.13 CGNS 

Website: http://www.cgns.org 

The CGNS library is used for working with hies written in CGNS format. 
CGNS is a convention for writing machine-independent, self-descriptive data 
hies for CFD and includes implementation software. Fun 3D has the capability 
to translate and write CGNS hies. The translation utilities are only compiled 
when CGNS is configured. Version 2.5 or greater of the CGNS library is 
required. To include CGNS, use 

— with-CGNS=/path/to/ cgns 

where /path/to/ cgns is the directory where the CGNS installation resides. 

A2 The tecio library that was shipped with Tecplot360-2008 had a bug that will result 
in error messages when the binary files are written. You must get an updated version of the 
library. 
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A.7.14 sBOOM 


Contact: Sriram.Rallabhandi@NASA.gov 

This package propagates a computed pressure signature to the ground for 
sonic boom simulations. Atmospheric variations are included, and an adjoint 
version is available for coupling into design and grid adaptation. sBOOM is 
distributed as a standalone executable or a static library. Fun 3D is not able 
to interact with the standalone executable; the static library must be linked. 
You may configure the Fun 3D suite to use the library via: 

— with-SBOOM=/path/to/ sBOOM 

where /path/to/sBOOM is the directory where the sBOOM installation re- 
sides. 
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Appendix B 


Fun 3D Input Files 


There are a variety of input files necessary for the various codes that make 
up the Fun 3D suite. Table B1 lists frequently used input hies with a short 
description. This chapter will describe the basic formats of each of these hies 
and meaning of the specihc inputs they contain. 


Table Bl: Fun3D input files. 

File Description 


stop.dat 

remove_boundaries_from_f orce_totals 

[project_rootname] .flow* 

fun3d.nml 

moving_body. input 

rotor. data 

tdata 

kinetic_data 
species_transp_data 
species_transp_data_0 
har a jname 1 i st _dat a 


signals a change to the number of iterations / 
time steps that were requested at the beginning 
of the run 

omits boundary faces from total force integra- 
tion 

flow field solution 

primary Fortran namelist (required) 

body motion Fortran namelist 

describes the rotor actuator disk model 

specifies the generic gas model 

specifies the possible chemical reactions in the 

generic gas model 

specifies generic gas model species collision cross 
sections 

specifies a higher-order generic gas model 

species collision cross sections 

controls the radiation models used by the Hara 

library 


* The [project_rootname] is a &project namelist variable, see section B.4.1. 


Fun 3D utilizes Fortran namelists for a large portion of input specification 
because it is defined in the Fortran 90 standard. With all Fortran namelists, 
leaving out or misspelling any namelist (defined with an ampersand preceding 
its name) will result in default values being used for all of the parameters within 
that namelist. For example, if the namelist name linear_solver_parameters 
were to be misspelled as linear _solver_parameter (missing s), then all pa- 
rameters within that namelist would be ignored and retain their default values. 
Leaving out any parameter within a namelist results in the default value for 
that parameter being used. Misspelling or misusing any particular parameter 
will typically cause Fun 3D to issue an error and stop. 
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B.l stop.dat 

This optional file either halts or extends the execution of the solver. The 
stop.dat plain text hie contains a single integer. After every iteration, the 
solver will check to see if this hie exists. If the hie is found in the directory 
that the solver was invoked, the integer is read and a message is printed to 
the standard output stream of the form, “stop.dat hie found, user requested 
stop at cycle N.” If the integer is greater than zero and less than or equal 
to the current iteration, the solver will write the current solution, delete the 
stop.dat hie, and halt execution. If the integer is less than zero, the solver will 
not write the restart hie, but will delete the stop.dat hie and halt execution. 

If the integer is zero, stop.dat will be ignored. 

The integer is with respect to the steps variable in the &code_run_control 
namelist and not with respect to a cumulative number of steps that may 
result from a restarted run. The value of the integer may be greater than 
the number of steps specihed in fun3d.nml’s &code_run_control namelist, 
so that stop.dat can be used to extend the execution of the solver. Some 
environments, especially ones with network-mounted filesystems (e.g., NFS), 
may exhibit a delay in the stop.dat hie being read or being deleted. 

B.2 [project_rootname] .f low 

The optional [project_rootname] .flow binary hie contains how solution and 
checkpoint information. The [project_rootnarae] is a feproject namelist 
variable, see section B.4.1. This hie is read by the solver to restart compu- 
tations from a previously computed how solution. The contents vary due to 
the checkpoint requirements of the simulation. The hie contains a minimum 
of the current solution and convergence history. It can also contain working 
variables for the turbulence model, solutions from previous iterations for time 
accurate cases, or previous grid positions and velocities for deforming grids. 

B.3 remove_boundaries_f rom_f or ce .totals 

The optional remove_boundaries_f rom_f orce_totals hie is for specifying bound- 
aries that are not to be included in the calculation of force and moment totals. 
This hie is useful, for example, in situations where there may be a mounting 
sting on a wind tunnel model, but only the forces on the model are actually of 
interest. The forces on the specihed boundaries are still computed and appear 
in the [project_rootname] .forces hie. However, they are not included in 
the totals. The position of the text lines in this hie is significant. So, follow 
this template carefully: 

Remove selected boundaries from the total forces 

Number of boundaries to turn off 
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2 

Boundaries to turn off (boundary lumping changes indexes) 

12 

15 

The third line is the number of boundaries to exclude. The fifth and subsequent 
lines are the patch indexes of the excluded boundaries. 


B.4 fun3d.nml 

The main input namelist hie, fun3d.nml, is described in detail below, with de- 
faults listed before the descriptions. The namelist hie contains a large number 
of input variables. In general, it is not necessary to specify them all because 
they have suitable default values. Only those variables that are different from 
the defaults need to be specihed. An overview of tasks and their associated 
namelists are listed below. 


The project name and grid information: 

&project (B.4.1) 

&raw_grid (B.4. 2) 

&force_moment_integ_properties (B.4. 3) 
&grid transform (B.4. 4) 

&body Transform (B.4. 5) 

The equation set and reference conditions: 

^governing equations (B.4. 6) 
&reference_physical_properties (B.4. 7) 
&noninertial_reference_frame (B.4. 8) 

The inviscid flux discretization: 

&inviscid flux method (B.4. 9) 

Turbulence model: 

&turbulent_diffusion_models (B.4. 10) 
&spalart (B.4. 11) 

&gammaretsst (B.4. 12) 
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Number of and size of time steps or steady iterations: 

&code_run_control (B.4.13) 

&nonlinear .solver .parameters (B.4. 14) 

Linear relaxation controls: 

&linear jsolver .parameters (B.4.15) 

&elasticity_gmres (B.4.16) 

Boundary conditions and transition: 

&boundary .conditions (B.4.17) 

&periodicity (B.4.18) 

&two_d_trans (B.4.19) 

&three_d_trans (B.4.20) 

Flowfield initialization: 

&flowdnitialization (B.4.21) 

Force tracking and visualization: 

&comp onent .parameters ( B . 4 . 2 2 ) 

&time_avg_params (B.4.23) 

&global (B.4.24) 

&volume .output .variables (B .4. 25) 
&boundary_output_variables (B.4.26) 

&sampling .output .variables (B.4.27) 
&sampling_parameters (B.4.28) 

&slice_data (B.4.29) 

Overset grid systems and rotorcraft simulation: 

&overset_data (B.4.30) 

&rotor_data (B.4.31) 

Grid adaptation: 

&adapt_metric_construction (B.4.32) 

&adapt .mechanics (B.4.33) 
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Design optimization cost functions: 

&massoud .output (B.4.34) 
&sonic_boom (B.4.35) 

&sboom (B.4.36) 

&equivalent_area (B.4.37) 
&press_box_fmiction (B.4.38) 
&pstag_fmictiou (B.4.39) 

Other: 

&special_parameters (B.4.40) 
&partitioniug (B.4.41) 
&fwh_acoustic_data (B.4.42) 
&vortex_generator (B.4.43) 
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B.4.1 ^project 

This namelist allows the user to specify the rootname of the project, which 
forms the majority of input and output filenames. 

&project 

project_rootname = ' def ault_project ' 

/ 


project_rootnarae = ’ default.project ’ 

The project rootname is the root for the grid, restart, and visualization 
files. The manual refers to it as [proj ect .rootname] . The ; def ault.proj ect ’ 
can be replaced with any filename allowed by the hie system. 
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B.4.2 fcraw grid 

This namelist specifies details of the grid format. 


&raw_grid 
grid_f ormat 
data_f ormat 
twod_mode 
swap_yz_axes 

f ieldview_coordinate_precision 
pat ch_ lumping 
ignore_euler_number 

/ 


' vgrid' 

1 default ' 
.false . 
.false . 

1 double ' 
'none ' 
.false . 


grid_f ormat = ’vgrid’ 

This specifies the grid file format. See section 4 for the details on these 
formats. The currently supported values are: 

'fast’ for FAST .fgrid/.mapbc files. 

' vgrid’ for single- and multi-segmented VGRID .cogsg/.bc/.mapbc files. 

‘fun2d’ for Fun 2D. faces files. 

' af lr3 ’ for AFLR3 formatted, unformatted, or C-binary/Fortran-stream 
.ugrid/.r8.ugrid/.b8.ugrid/.mapbc files, 

' f elisa’ for Felisa grid files. 

' f ieldview’ for FieldView formatted or unformatted .fvgrid fmt/.fvgrid unf/.mapbc 
files. 

data_f ormat = ’default’ 

This provides the encoding of the grid file. A particular grid_f ormat 
may only support a subset of encodings. Fun 3D will stop with an error 
message if the data_format is inconsistent with the grid_f ormat. The 
’ default ’ value is changed to an admissible value based on grid_f ormat 
as noted next to each value, 

'ascii’ ASCII text grid file. It is the default for ’felisa’ and ’fun2d’ 
grids. 

'unformatted’ Fortran unformatted grid file. It is the default for 
’fast’, ’vgrid’, and ’f ieldview’ grids. 

' stream’ C-binary/Fortran-stream grid file. It is the default for ’ af lr3’ 
grids. 

' stream64’ 64 bit integer C-binary/Fortran-stream grid file. 
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twodunode = .false. 


Turns on two-dimensional mode for a single layer prism or hex grid. If 
grid_format = ’fun2d’, twodunode is automatically .true.. 

swap_yz_axes = .false. 

When .true., this swaps the y- and t-axes for the grid. This option can 
be used to rotate the grid so the z-axes is in the Fun 3D convention for 
angle of attack and lift. 

f ieldview_coordinate_precision = ’ double’ 

This specifies floating point precision of reals for FieldView meshes only. 

‘ double ’ for double precision coordinates. 

‘ single’ for single precision coordinates. 
patch_lumping = ’none’ 

This enables boundary patch lumping. It combines the grid patches into 
fewer patches to ease the bookkeeping of patch groups, but will effect all 
features that reference boundary patch numbers (e.g., &boundary_conditions). 
The .mapbc hies for any of the supported grid formats may contain an 
optional third column of data, which specifies a family name. The ex- 
ception is the VGRID. mapbc hie, where the family name is mandatory 
and appears in the sixth column. If family names are not present in the 
.mapbc hie, patch_lumping can not be family. 

' none ’ for no patch lumping. 

‘ be ’ for physical boundary condition lumping. 

'family’ for family name lumping 

ignore_euler_number = .false. 

This will permit the use of grids with a failing Euler number check. See 
section C.9 for a description of the Euler number and its implications. 
Ignoring the Euler number check is not recommended. 
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B.4.3 &force moment integ properties 


Reference lengths and area are defined in this namelist to scale aerodynamic 
force and moment data. 

&f orce_moment_integ_properties 
area_ref erence = 1.0 
x_moment_ length = 1.0 
y_moment_ length = 1.0 
x_moment_ center =0.0 
y_moment_ center = 0.0 
z_moment_center =0.0 

/ 

area_ref erence = 1.0 

This area is used for non-dimensionalization of forces and moments, spec- 
ified in grid units squared. For a semi-span model, use half of the full 
configuration reference area. 

xjnoment_length = 1.0 

This length in x- direct ion is used to nondimensionalize moments about 
y (pitching moment), specified in grid units. 

yjnoment_length = 1.0 

This length in ^/-direction is used to nondimensionalize moments about 
x (rolling moment) and 2 (yawing moment), specified in grid units. 

x_moment_center = 0.0 

This specifies the x-coordinate location of moment center, in grid units. 
ynnoment_center = 0.0 

This specifies the ^/-coordinate location of moment center, in grid units. 
zunomentncenter = 0.0 

This specifies the x-coordinate location of moment center, in grid units. 
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B.4.4 &grid transform 

This namelist defines a constant grid translation and rotation that is applied 
before the start of the flow solution. For example, original grid may be reori- 
ented to position the geometry at a different angle of attack. 


&grid_transf orm 


ds 

= 

0.0 




sx 

= 

1.0 




sy 

= 

0.0 




sz 

= 

0.0 




theta 

= 

0.0 




tx 

= 

1.0 




ty 

= 

0.0 




tz 

= 

0.0 




xO 

= 

0.0 




yo 

= 

0.0 




z0 

= 

0.0 




scale 

= 

1.0 




transf orm(l , 1 : 4) 

= 

1.0, 

0.0, 

0.0, 

0.0 

transf orm(2, 1 :4) 

= 

0.0, 

1.0, 

0.0, 

0.0 

transf orm(3, 1 :4) 

= 

0.0, 

0.0, 

1.0, 

0.0 

transf orm(4, 1 : 4) 

= 

0.0, 

0.0, 

0.0, 

1.0 


/ 

ds = 0.0 

This is the translation distance. 

sx = 1.0 

This is the ^-component of a unit vector in the translation direction, 
sy = 0.0 

This is the ^/-component of a unit vector in the translation direction. 
sz = 0.0 

This is the z-component of a unit vector in the translation direction. 
theta = 0.0 

This is the rotation angle (in degrees). A positive rotation is applied by 
the right hand rule with the thumb pointing in direction of rotation axis. 

tx = 1.0 

This is the ^-component of the rotation axis unit vector, 
ty = 0.0 

This is the ^/-component of the rotation axis unit vector. 
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tz = 0.0 

This is the z-component of the rotation axis unit vector. 
xO = 0.0 

This is the ^-coordinate of the rotation origin. 
yO = 0.0 

This is the //-coordinate of the rotation origin. 
zO = 0.0 

This is the z-coordinate of the rotation origin. 
scale = 1.0 

This a scale factor applied to all coordinate values. 

transf orm(l , 1 : 4) = 1.0, 0.0, 0.0, 0.0 

This is a 4x4 transform matrix (see for example [27]). 
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B.4.5 &body transform 

This namelist defines a constant body translation and rotation that is applied 
before the start of the flow solution. For example, original body may be 
reoriented to position the geometry at a different effective angle of attack. 
After repositioning the body, the mesh is deformed once to reflect the new 
position of the body, before beginning the solution. 

&body_tr ansf orm 
n_bodies 
nbndry ( : ) 
boundary_list ( : ) 
ds ( : ) 
sx( : ) 
sy ( : ) 
sz( : ) 
theta( : ) 
tx( : ) 
ty(:) 
tz( : ) 
x0( : ) 
y0( : ) 

z0( : ) 

tr ansf orm ( 1 , 1 : 4 , 1 ) 
transf orm(2, 1:4,1) 
transform (3, 1:4,1) 
transf orm (4, 1:4,1) 

/ 

n_bodi.es = 0 

This is the number of bodies that are to be repositioned at the start of 

the computation. 

nbndry ( : ) =0 

This is the number of boundary patches listed for a given body. 

boundary_list ( : ) = ’’ 

This is a list of boundary patch numbers for a given body. Commas and 

dashes can be used to specify ranges, i.e., ’ 1 , 2 , 5-7 J . 

ds ( : ) - 0.0 

This is the translation distance. 

sx(:) = 1.0 

This is the ^-component of a unit vector in the translation direction. 


= 0 

= 0 
— I I 


= 

o 

o 




= 

o 

T- 1 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

H 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

H 

0.0, 

0.0, 

O 

o 

= 

o 

o 

1.0, 

0.0, 

o 

o 

= 

o 

o 

0.0, 

1.0, 

o 

o 

= 

o 

o 

0.0, 

0.0, 

1.0 
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sy ( : ) = 0.0 

This is the ^/-component of a unit vector in the translation direction. 


sz( : ) = 0.0 

This is the ^-component of a unit vector in the translation direction. 
theta(:) = 0.0 

This is the rotation angle (in degrees). A positive rotation is applied by 
the right hand rule with the thumb pointing in direction of rotation axis. 

tx(:) = 1.0 

This is the ^-component of the rotation axis unit vector. 
ty(:) = 0.0 

This is the ^/-component of the rotation axis unit vector. 
tz( : ) = 0.0 

This is the ^-component of the rotation axis unit vector. 
xO ( : ) = 0.0 

This is the ^-coordinate of the rotation origin. 
yO ( : ) = 0.0 

This is the ^-coordinate of the rotation origin. 
zO ( : ) = 0.0 

This is the z-coordinate of the rotation origin, 
transf orm(l , 1 : 4, 1) = 1.0, 0.0, 0.0, 0.0 
This is a 4x4 transform matrix (see for example [27]). 
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B.4.6 ^governing equations 


This namelist specifies the equation set that describes underlying physics of 
the problem. 

&governing_equations 

eqn_type = 

artif icial_compress = 

viscous_terms 
chemical_kinetics 
thermal_energy_model = 

prandtlnumber_molecular = 

schmidt_number 
gas_radiation 

rad_use_impl_lines = 

multi_component_dif f = 

cpiv_min_f actor 
augment_kinetics_limiting = 
implicit_rate_limiting 
therm_f ac_lim = 

/ 

eqnrtype = ’compressible 

This specifies the set of governing equations to be solved. 

‘ compressible ’ for compressible, calorically perfect gas. See section 2.1 
for equations and nondimensionalization. 

'incompressible’ for incompressible, calorically perfect gas. [28] See 
section 2.2 for equations and nondimensionalization. The incompress- 
ible solution is affected by the choice of artif icial_compress, see the 
description of this parameter for details. 

‘generic’ for multispecies, reacting gas simulations. See section 2.3 
for nondimensionalization. The tdata input file is required. Fun 3D is 
usually distributed with the ’ generic ’ option disabled. If it is required, 
see section 1.4 for information on obtaining the version of Fun 3D with 
this capability. 

artif icial_compress = 15.0 

This is the artificial compressibility factor, /?, which is only used by the 
eqnrtype = ’incompressible’. This parameter must be in the range 
of (100,1). See Anderson, Rausch, and Bonhaus [28] for details. The 
sensitivity of the solution to this parameter will decrease with mesh 
refinement, so consider a refined grid if an unacceptable amount of sen- 
sitivity is experienced. A high sensitivity to this parameter can also 


' compressible ' 
15.0 

' turbulent ' 

1 finite-rate ' 

1 non-equilib ' 

0 . 72 
- 1 . 

'off' 

.false . 

.false . 

0.0001 
.false . 

. true . 

1. e+20 
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indicate that the problem is actually compressible and the user is en- 
couraged to check the incompressible solution by performing a low Mach 
compressible simulation. 

viscous_terms = ’ turbulent ’ 

This describes the modeling of the viscosity term in the governing equa- 
tions. 

' inviscid’ no viscosity, for inviscid flow. 

' laminar ’ apply laminar viscosity, to model laminar flow. 

' turbulent ’ include laminar viscosity and model turbulent flow with a 
feturbulent.dif fusion-models. 

chemical_kinetics = ’ finite-rate ’ 

This describes the chemical kinetics, only used when eqn.type = ’ generic ’ . 
' frozen ’ for frozen chemical compositions. 

'finite-rate’ for finite-rate reacting gases. 
thermal_energy .model = ’non-equilib’ 

This describes the thermal energy model, only used when eqn.type = 

’ generic ’ . 

'frozen’ for frozen chemical compositions. 

'non-equilib’ for non-equilibrium gases. 

prandtlnumber_molecular = 0.72 

This is the molecular Prandtl number, ft must be greater than zero. 

schmidt .number = -1. 

This is the Schmidt number used in the generic gas path. If the user 
wants to override the default path of computing a variable Schmidt num- 
ber from collision cross sections then use this parameter to specify the 
constant Schmidt number. 

gas_radiation = ’off’ 

This controls flow held radiation coupling. When active, this option will 
compute radiation source terms and surface heat fluxes after the first 
time step. Radiation source terms are not further updated during the 
rest of the time steps. Radiation source terms are not stored in the 
restart hie, so they need to be recalculated when restarting simulations 
that include how held radiation. Only for eqn -type = ’generic’. 

' of f ’ no radiation calculations. 
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‘ uncoupled ’ will use the HARA program to compute radiative surface 
heat fluxes, but radiation source terms would not be included in the 
flow-held governing equations. 

‘ coupled ’ will include radiation source terms in the governing equa- 
tions, with the divergence of the radiative flux being computed by the 
HARA program. Requires rad_use_impl_lines = .true.; only valid if 
all of the domain nodes are included in one and only one line as defined 
by the implicit lines hie. 

rad_use_impl_lines = .false. 

For gas .radiation, the mesh nodes in the lines of sight are read from the 
implicit lines hie. Coupled radiation must use this option. For uncoupled 
radiation, the lines of sight can either be read from the implicit lines hie 
when .true., or the lines of sight will be generated during the FUN3D 
run when .false. Only for eqn.type = ’generic’. 

multi.component.dif f = .false. 

When .true., engage multi-component diffusion using sub-iteration of 
Stefan-Maxwcll Equations as described by Sutton and Gnoffo. [29] Oth- 
erwise, use binary diffusion with mass fraction averaged correction to 
force sum of diffusion hux to equal zero. Only for eqn.type = ’generic’. 

cpiv_min_f actor = 0.0001 

This variable sets the minimum value of the vibrational-electronic heat 
capacity as a fraction of the translational-rotational heat capacity for 
each species i. In some cases, ramping this value up to 0.01 can help 
suppress undershoot of vibrational temperature upstream of a strong 
shock. The vibrational-electronic heat capacity must be positive for 
stability. Only for eqn.type = ’generic’. 

augment _kinetics_limiting = .false. 

When .true., augment chemical kinetic source term limiting. Only for 
eqn.type = ’generic’. 

implicitxrate.limiting = .true. 

When .true., limit chemical rates if extrema exist in formulation Only 
for eqn_type = ’generic’. 

therm_f ac_lim = l.e+20 

This factor limits the magnitude of the thermal relaxation rate. The 
default represents an essentially unlimited value. For simulations where 
thermal nonequilibrium is only evident at the shock front or in a highly 
expanded wake, the user may observe convergence problems associated 
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with stiffness because the major part of the flowheld is in thermal equi- 
librium. In these cases, the stiffness can be alleviated by setting this 
parameter to a value which is large enough to maintain thermal equilib- 
rium where it is appropriate but small enough that stiffness is removed. 
If used, a starting value of 5.e+05 is recommended. If this limiting factor 
is too large, stiffness is not alleviated. If this limiting factor is too small, 
thermal equilibration is prevented in a non-physical manner. Only for 
eqn.type = ’generic’. 
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B.4.7 Preference physical properties 

This namelist is used to specify reference conditions and nominal freestream 
flow conditions in a user-defined unit system. It is also used to convert between 
grid units and flow solver units. 


&ref erence_physical_properties 


dim_ input _type 

gridlength_conversion 

mach_number 

vinf _ratio 

reynolds_number 

velocity 

density 

temperature 

temperature_units 

angle_of _attack 

angle_of _yaw 


' nondimensional ' 
1.0 
0.0 
1.0 
0.0 
0.0 
0.0 
273.0 
' Kelvin ' 

0.0 

0.0 


dim_input_type = ’ nondimensional ’ 

This is the system of measurement for the reference conditions. Cur- 
rently, it must be ’dimensional-SI’ for eqn_type = ’ generic ’ and 
’ nondimensional ’ otherwise. This input is intended for future expan- 
sion. The temperature is always input as a dimensional quantity. 

‘ nondimensional ’ requires mach_number and reynolds_number to be 
defined. 

‘dimensional-SI’ requires dimensional velocity and density to be 
defined. 

gridlength.conversion = 1.0 

For dim_input_type = ’dimensional-SI’, this is the conversion fac- 
tor to scale the grid and it should be set to meters per grid unit. It 
is used for providing heat flux in proper units and other tasks. For 
dim_input_type = ’ nondimensional ’ , this should be set to 1.0, be- 
cause the grid is already in nondimensional grid units. 

mach_number = 0,0 

This is the reference Mach number defined as velocity/speed-of-sound. It 
is only allowed for dim_input_type = ’ nondimensional ’ and eqn.type 
= ’ compressible’ . It must be set to a positive value. 


vinf_ratio = 1.0 


This is a multiplicative factor that is applied to the reference velocity. 
The effective freestream velocity for the simulation is then vinf .ratio x 
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ref erence.velocity. The default value of vinf .ratio gives a freestream 
velocity identical to the reference velocity. Note that for eqn.type = 

’ compressible ’ , the reference velocity has magnitude mach_number, 
while for eqn.type = ’ incompressible ’ , the reference velocity has mag- 
nitude 1. For either eqn_type, a value of vinf_ratio different from 
unity allows distinct freestream and reference conditions. This is of- 
ten used, for example, in rotorcraft simulations where the tip Mach 
number is taken as the reference Mach number, while the freestream 
Mach number reflects the forward speed, vinf .ratio is not applicable 
to eqn.type = ’ generic ’ 

reynolds_number =0.0 

This is the reference Reynolds number, per one unit of the grid. Not 
correctly accounting for the unit of the grid has been a point of confusion 
in the past. For example, when the grid units are feet, Reynolds number 
should be specified per foot. This input is only used if dim_input_type = 

’ nondimensional ’ and is ignored by eqn.type = ’ generic’ . It must 
be set to a positive value. 

velocity = 0.0 

This is the reference velocity, in m/s. Only used for dim.input.type = 

’ dimensional-SI ’ and eqn.type = ’generic’. 

density = 0.0 

This is the reference density, in kg/m 3 . Only used for dim_input_type 
= ’ dimensional-SI ’ and eqn.type = ’generic’. 

temperature = 273.0 

This is the reference temperature, in units of temperature.units. 
temperature.units = ’Kelvin’ 

The units used to specify temperature. 

'Kelvin’ for SI units. 

' Rankine ’ for the English system, 
angle.of .attack = 0.0 

This is the freestream angle of attack in degrees. 

angle.of.yaw = 0.0 

This is the freestream angle of yaw (side-slip) in degrees. 


130 



B.4.8 &noninertial reference frame 


FUN3D can perform simulations in noninertial reference frame rotating at a 
constant rate, fl The noninertial reference frame simulation can be run as a 
steady state problem if the freestream velocity crossed with the rotation vector 
is zero, Uoo x = 0. In a practical sense, freestream velocity should be zero 
or parallel to the axis of rotation. Using a standard inertial reference frame 
requires the same problem to be run as an unsteady simulation at a larger 
computational cost. Typical uses would be the simulation of an isolated rotor 
in hover (without forward motion) or an aircraft performing a steady-state 
pitching maneuver or constant roll about the wind axis. 


&noninertial_ref erence frame 
noninertial 
rotation_center_x = 
rotation_center_y = 
rotation_center_z = 
rotation_rate_x 
rotation_rate_y 
rotation_rate_z 

/ 

noninertial = .false. 

When .true., use a noninertial reference frame. The default is the inertial 
reference frame. 

rotation_center_x = 0.0 

This is the x of the steady rotation rate center point. 
rotation_center_y = 0.0 

This is the y of the steady rotation rate center point. 
rotation_center_z = 0.0 

This is the z of the steady rotation rate center point. 
rotation_rate_x = 0.0 

This is the steady noninertial rotation rate (nondimensional) about the 
rotation center x-axis. For eqn.type = ’ compressible ’ , the nondi- 
mensional rate is u = u — , where lu* is the dimensional rota- 

a ref-^ref 

tion rate about the rotation center x-axis, in rad/sec. For eqn.type = 
’ incompressible ’ , the nondimensional rate is u = — W — ; see also 

section 2. 


.false . 
0.0 
0.0 
0.0 
0.0 
0.0 
0.0 
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rotation_rate_y = 0.0 

This is the steady noninertial rotation rate (nondimensional) about the 
rotation center y-axis. For eqnxtype = ’ compressible ’ , the nondi- 
mensional rate is u = u ^ — , where a ;* * is the dimensional rota- 

a refl^ref 

tion rate about the rotation center y-axis, in rad/sec. For eqnxtype = 
’ incompressible’ , the nondimensional rate is u = — r -¥- — ; see also 

section 2. 

rotation_rate_z = 0.0 

This is the steady noninertial rotation rate (nondimensional) about the 

rotation center z-axis. For eqn.type = ’ compressible ’ , the nondi- 

mensional rate is u = to *—: — r -¥- — , where to* is the dimensional rota- 

tion rate about the rotation center z-axis, in rad/sec. For eqn.type = 

L* 

’ incompressible’ , the nondimensional rate is u = to*T 7 i — — ; see also 

* ref^ref 

section 2. 
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B.4.9 &inviscid flux method 


This namelist controls the construction of the inviscid fluxes and flux Jaco- 
bians. 


&inviscid_f lux_method 
f lux_construction 
f lux_construction_lhs 
kappa_umuscl 
f lux_limiter 
smooth_limiter_coef f 
f reeze_limiter_iteration = 
f irst_order_iterations 
mult idm_opt ion 
f ixed_direction 
recalc_dir_freq 
adptv_entropy_f ix 
rhs_u_eigenvalue_coef 
lhs_u_eigenvalue_coef 
rhs_a_eigenvalue_coef 
lhs_a_eigenvalue_coef 
entropy_fix 
temperature_f ix 
re_min_vswch 
re_max_vswch 
pole_gradient 


1 roe ' 

' vanleer ' 
- 1.0 
' none ' 

1.0 

-1 

0 

1 

. true . 

1 

.false . 

0 . 

0. 

0 . 

0 . 

.false . 
.false . 
50 . 

500 . 
.false . 


f lux.construction = ’roe’ 

This specifies the inviscid flux residual construction method. 

‘ roe ’ for Roe flux difference splitting. 

‘ vanleer ’ for van Leer flux vector splitting. 

‘ hllc ’ for HLLC. 

‘ auf s ’ forAUFS. 

‘ ldf ss ’ for LDFSS. 

‘dldfss’ for dissipative LDFSS. 

‘ aldfss J for LDFSS with an adaptive entropy fix. 

< roe_ec J for entropy-consistent Roe scheme. 

‘ stvd ; for Yee’s symmetric total variation diminishing scheme. 
‘ stvd_modif ied’ for a modified version of STVD. 

< multidnR for Gnoffo’s multidimensional scheme. 
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f lux_construction_lhs = ’vanleer’ 

This specifies the inviscid flux Jacobian construction method. A ’ consistent ’ 
method yields the best asymptotic iterative convergence rate of the non- 
linear residual, but a more diffusive flux may stabilize a poorly converging 
or diverging linear system iterative scheme. 

'consistent’ for a consistent linearization with the residual construc- 
tion method. 

'vanleer’ for Van Leer. 

' roe ’ for Roe linearization. 

‘hllc’ for HLLC. 

' auf s ’ forAUFS. 

' ldf ss ’ for LDFSS. 

kappammuscl = -1.0 

Controls the amount of upwinding in the unstructured-grid MUSCL re- 
construction scheme. The default will adjust kappa.umuscl internally 
to 0.5 for 3D mixed-element grids or 0.0 for all other grid types. 0.0 is 
the upwind-biased (Fromm) discretization, 1.0 is the (unstable) central- 
difference discretization, and the range [0,1] is a blend of the two. 

f lux_limiter = ’none’ 

This selects the flux limiter. The limiters that begin with the letter h, 

’ barth ’ , and ’ venkat ’ are stencil-based limiters (they apply a limiter 
to each edge in a node’s the reconstruction stencil and store the most 
restrictive edge limiter value at the node). Other limiters are evaluated 
in a strictly edge-based manner. The h-series of limiters automatically 
turns on a heuristic pressure based limiter that is used to augment the 
selected flux limiter. [30] The node-based limiters can be frozen with the 
freeze_limiter_iteration namelist variable described below. Note: 

The adjoint solver is only compatible with a frozen limiter flow solution. 

For hypersonic flows computed using the calorically perfect gas path, the 
hvanleer or hvanalbada flux limiters are recommended. The smooth 
class of limiters use the smooth_limiter_coef f as noted in the limiter 
descriptions. 

' none ’ for no limiter. 

'barth’ for the Barth limiter. 

' venkat ’ for the Venkat akr is hnan [31] limiter. This limiter relies on a 
user-tunable parameter, sraooth_limiter_coef f . 

' hminmod’ for the stencil-based min- mod limiter augmented with a heuris- 
tic pressure limiter. 
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‘hvanleer’ for the stencil-based van Leer limiter augmented with a 
heuristic pressure limiter. 

‘hvanalbada’ for the stencil-based van Albada limiter augmented with 
a heuristic pressure limiter. This limiter relies on a user-tunable param- 
eter, smooth_limiter_coef f . 

‘ hvenkat ’ for the Venkatakrishnan limiter augmented with a heuris- 
tic pressure limiter. This limiter relies on a user-tunable parameter, 
sraooth_limiter_coef f . 

‘ mininod J for the min-mod limiter. 

‘vanleer’ for the van Leer limiter. 

< vanleer_gg ) for van Leer limiter that also turns on Green-Gauss gra- 
dients for inviscid reconstruction. 

‘vanalbada’ for the van Albada limiter. 

smooth_limiter_coef f = 1.0 

This is the coefficient used to tune smooth limiters, such as ’ venkat ’ . 
Larger values of smooth_limiter_coef f reduce the effect of the limiter, 
tending toward the unlimited solution, with (typically) better conver- 
gence properties at the expense of increased oscillations near shocks. 
This class of smooth limiters assume that the geometry in the mesh 
is 0(1), i.e., that the grid is normalized to a characteristic length of 
your model. When the geometry is not 0(1), a suggested value for 
sraooth_limiter_coef f is proportional to the reciprocal of a character- 
istic length, e.g., proportional to l/(Mean Aerodynamic Chord). By 
way of example, assume you have a grid in which the mean aerody- 
namic chord is 1.0, and you were satisfied with the solution properties 
and convergence with a value of smooth_limiter_coeff = 3.0. Then 
assume you scale this mesh so that the mean aerodynamic chord is 10.0. 
Running the scaled mesh at the same flow conditions would require that 
smooth_limiter_coef f = 3.0/10.0 to achieve the same solution proper- 
ties and convergence as the unsealed mesh. 

freeze_limiter_iteration = -1 

The node-based limiters can be frozen with f reeze_liraiter_iteration 
equal to zero or an iteration number. A negative value does not freeze 
the limiter. Zero is used to retain the limiter held contained in the restart 
hie. Freezing a limiter can reduce nonlinear iterative convergence “ring- 
ing.” [31] Freezing is typically engaged at 3/4 of the iterations required 
for convergence. The steady decline of the low frequency residual modes 
tend to continue at similar rate with or without freezing, you just can’t 
see it in the ringing residual norm. The later you wait to freeze the 
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limiter, the closer the frozen limiter solution is to the converged answer. 
If a unrealizable reconstruction (negative density or pressure) is encoun- 
tered the limiter held will be locally updated at the node experiencing 
the problematic reconstruction. The adjoint solver is only compatible 
with a frozen limiter. 

f irst_order_iterations = 0 

This is the number of iterations to use first-order spatial accuracy prior 
to using second-order spatial accuracy. If second-order spatial accuracy 
in not required, set this to a value larger than the number of steps. 
This option is useful for starting difficult supersonic how simulations. 
For time accurate cases (time_accuracy not equal to ’steady’), this 
is the number of hrst-order accurate sub-iterations to run for each time 
step. 

multidm_option = 1 

This controls the multidm reconstruction weighting. 

‘ 1 ’ virtual node averaging. 

‘ 2 ’ weighted average of edges. 

f ixed_direction = .true. 

This specihes the use of Cartesian directions in multdm reconstruction. 
recalc_dir_freq = 1 

This sets the frequency of direction recalculation in the multidm scheme. 
adptv_entropy_f ix = .false. 

This activates the adaptive entropy hx for Roe’s scheme. 

rhs_u_eigenvalue_coef = 0. 

This is the contact /shear eigenvalue smoothing coefficient for the adap- 
tive entropy hx and the roe residual. It increases dissipation to improve 
robustness with the penalty of reduced solution accuracy. 

lhs_u_eigenvalue_coef = 0. 

This is the contact /shear eigenvalue smoothing coefficient for the adap- 
tive entropy hx and the roe Jacobian. It increases dissipation to improve 
robustness of the linear solve with the potential penalty of reduced non- 
linear convergence if it is different from rhs_u_eigenvalue_coef . 

rhs_a_eigenvalue_coef = 0. 

This is the acoustic eigenvalue smoothing coefficient for the adaptive 
entropy hx and the roe residual. It increases dissipation to improve 
robustness with the penalty of reduced solution accuracy. 
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lhs_a_eigenvalue_coef = 0. 

This is the acoustic eigenvalue smoothing coefficient for the adaptive 
entropy fix and the roe Jacobian. It increases dissipation to improve 
robustness of the linear solve with the potential penalty of reduced non- 
linear convergence if it is different from rhs_a_eigenvalue_coef . 

entropy_fix = .false. 

This activates the entropy fix for the stvd flux. 
temperature_f ix = .false. 

This activates the temperature fix for undershoots with the stvd flux. 
re_min_vswch = 50. 

For the stvd flux, eigenvalue limiting is turned off below this cell Reynolds 
number. 

re_max_vswch = 500. 

For the stvd flux, eigenvalue limiting is fully engaged above this cell 
Reynolds number. 

pole_gradient = .false. 

If true, use limiting form of continuity equation across pole in association 
with symmetry_l_strong, symmetry _2_strong, or symmetry_3_strong. 
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B.4.10 ^turbulent diffusion models 

When viscous .terms = ’turbulent’, this namelist is used to set the form 
of the turbulence model. 


&turbulent_dif fusion_models 
turbulence_model = 

turb_model 

turb_intensity = 

turb_viscosity_ratio = 
reynolds_stress_model = 
turb_compress_model 
turb_conductivity_model = 
prandtlnumber_turbulent = 
schmidtnumber_turbulent = 
wall_function = 


' sa' 

1 deprecated-use-turbulence_model ' 
0.001 
0.001 
1 linear ' 

'off' 

'off' 

0 . 9 

1 . 

'none ' 


/ 


turbulenceunodel = ’sa’ 

This selects the form of the turbulence model. The naming convention 
of http://turbmodels.larc.nasa.gov/ is used for the models described 
on the website. 

‘ sa’ for Spalart-Allmaras model. [32] See the &spalart namelist in sec- 
tion B.4.11 for additional controls. 

‘sa-catris’ for Spalart-Allmaras Catris-Aupoix model. [33] 

‘des’ for Spalart-Allmaras based DES model. [34] See the fespalart 
namelist in section B.4.11 for additional controls. Not available for 
eqn_type= ’ generic ’ . 

‘ sa-neg’ for Spalart-Allmaras model with negative turbulence variable 
provisions. [35] Not available for eqn_type= ’ generic ’ . 

‘des-neg’ for Spalart-Allmaras based DES model with negative turbu- 
lence variable provisions. [34,35] Not available for eqn_type= ’ generic ’ . 

‘menter-sst’ option is no longer valid, use sst or sst-v 

‘ bsl ’ Menter Baseline Two-Equation Model. [36] 

‘ sst’ Menter SST Two-Equation Model with strain source term. [36] 

‘sst-v’ Menter SST Two-Equation Model with vorticity source term. 
[37] Not available for eqn_type= ’ generic ’ . 

‘wilcoxl988’ Wilcox (1988) k-omega Two-Equation Model. [38] Not 
available for eqn_type= ’ generic ’ . 

‘ wilcoxl988-v’ Wilcox (1988) k-omega Two-Equation Model with vor- 
ticity source term. [38] Not available for eqn_type= ’ generic ’ . 
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‘ ¥ 1100 x 2006 ’ Wilcox (2006) k-omega Two-Equation Model. [39] Not 
available for eqn_type=’ generic ’ . 

‘ wilcox2006-v’ Wilcox (2006) k-omega Two-Equation Model with vor- 
ticity source term. [39] Not available for eqn_type= 5 generic ’ . 

‘hrles’ for Menter SST-based hybrid-RANS/LES model. [40,41] Does 
not work with eqn_type= ’ generic ’ . 

‘ gamraa-ret-sst ’ for Langtry and Menter SST transition model. [42] 

See the fegaramaretsst namelist in section B.4.12 for additional controls. 

Not available for eqn_type= ’ generic ’ . 

‘ baldwin-lomax’ Baldwin-Lomax algebraic model. Available only for 
eqn_type= ’ generic ’ . 

‘ cebeci-smith’ Cebeci-Smith algebraic model. Available only for eqn.type 
generic. 

turbnnodel = ’ deprecated-use-turbulence_model ’ 

This is a deprecated namelist variable for turbulence_model. It is in- 
cluded for backwards compatibility with fun3d.nml hies, but may be 
removed in a future version. 

turb.intensity = 0.001 

This sets the freestream turbulence intensity, -J where k is the tur- 
bulent kinetic energy. Only applies to eqn_type= ’ generic ’ . 

turb_viscosity_ratio = 0.001 

This sets the freestream ratio of turbulent viscosity to molecular viscos- 
ity. Only applies to eqn_type= ’ generic ’ . 

reynolds_stress_model = ’linear’ 

This controls the mean stress-strain constitutive relation. 

‘ linear’ indicates the use of the linear Boussinesq assumption. 

‘ qcr ’ activates the Quadratic Constitutive Relationship (QCR) of Spalart. 
[43] This non-linear model is not valid for explicit algebraic Reynolds 
stress or full Reynolds stress transport models (e.g., ASM, EASM, RSM 
models). 

turb_compress_model = ’off’ 

This controls the turbulence compressibility model. Only applies to 
eqn_type= ’ generic ’ . 

‘ off ’ for no correction. 

‘ssz’ for SSZ (use with Spalart- Allmaras models). 
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‘zeman’ for Zeman (use with k — e models). 

‘wilcox’ for Wilcox (use with SST-based models). 

‘ sarkar J for Sarkar (use with k — e models). 
turb_conductivity_model = ’off’ 

This controls whether a turbulence conductivity model is employed. 
Only applies to eqn_type= ’ generic ’ . 

‘ off ’ to turn off a turbulence conductivity model. 

‘ on ’ to turn on a turbulence conductivity model. 

prandtlnuraber_turbulent = 0.9 

This is the turbulent Prandtl number. 

schmidtnumbervturbulent = 1. 

This is the turbulent Schmidt number. Only applies to eqn_type= ’ generic ’ . 

wall_function = ; ’none , 

This is the name of the wall function model. 

'none’ integrates to the the wall (no wall function). 

'dir’ utilizes the wall function of Knopp, Alrutz, and Schwamborn. 

[44] Can be used with turbulence_model = ’sa’, turbulencennodel 
= ; sst ’ , or their variations. 
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B.4.11 &:spalart 

This namelist is used to modify details of the SA and SA based DES turbulence 
models. 


fespalart 

turbinf 

dacles_mariani 


= 3.0 


= .false. 
= .false. 
= .false. 
= .false. 
= 0.975 


sarc 

ddes 


ddes_modl 

cddes 


/ 


turbinf = 3.0 

This is the freestream turbulence value for the SA model. 
daclesanariani = .false. 

This activates the Dacles-Mariani [45,46] rotation correction (denoted 
SA-R by http://turbmodels.larc.nasa.gov/). 

sarc = .false. 

This activates the rotation/curvature correction [47] (denoted SA-RC by 
http : / / turbmodels.larc.nasa.gov/). 

ddes = .false. 

This changes the turbulence_model= ’ des ’ into Delayed DES [48] (DDES) 
ddes_modl = .false. 

This changes the turbulence_model=’des’ into Modified Delayed DES 
[49] (MDDES). It also requires ddes = .true. This option should be used 
with caution. Most experience with this model is for large separated 
flows encountered in wake regions of bluff bodies, such as cylinders and 
landing gears. Further validation is required for other situations. There 
is sensitivity to the parameter cddes. 

cddes = 0.975 

This is Cmdd hi [49]. It used with the ddes_modl = .true. 
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B.4.12 &gammaretsst 


This namelist modifies the details of the turbulence_model = ’ gamma-ret-sst ’ 
transition turbulence model of Langtry and Menter. [42] Correctly setting the 
freestream levels of turbulence is key to the transition location of this model. 
Ideally, freestream turbulence levels are measured in an experiment. 

&gammaretsst 

set_k_inf _w_turb_intsty_percnt = -1.0 
set_w_inf _w_eddyviscosity = -1.0 

/ 


set_k_inf _w_turb_intsty_percnt = -1.0 

This is the freestream turbulence level as a percentage. A negative value 
uses the default ^ = 9 x 10 -9 . A positive value will set k ^ = 1.5 x 
(0.01 x M x set_k_inf _w_turb_intsty_percnt) 2 . 

set_w_inf _w_eddyviscosity = -1.0 

This is the freestream eddy viscosity as the ratio between turbulent eddy 
viscosity to laminar viscosity. A negative value uses the default = 
10~ 6 . A positive value will set u oo = /Coo/set_w_inf _w_eddyviscosity. 
If not available, a value in the range of 0.05 to 5 is commonly used, but 
the appropriate value is case specific. 
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B.4.13 &code run control 


This namelist controls the length of the simulation. Restart options, Jacobian 
update strategy, and angle of attack continuation can also be specified. 

&code_run_control 
steps 

stopping_tolerance 
duration_limit_in_minutes 
no_restart 
restart_write_f req 
restart_read 
smart_j update 
j acobian_eval_f req 
jupdate_startup_steps 
jupdate_amut_max_ change 
jupdate_cf l_inv_change 
df duc3_ j acobians 
alpha_sweep 
cycle_ increment 
alpha_ increment 
alpha_max 
alpha_min 
alpha_switchbacks 
wr it e_steady_re start 
sd_f ile_f ormat 

/ 

steps = 500 

This is the number of time steps or steady iterations to perform. 

stoppingvtolerance = l.e-15 

This instructs the solver to terminate before all steps are complete when 
the root mean square (RMS) of every equation (continuity, energy, etc.) 
is less than this tolerance. 

duration_limit_in_minutes = -1.0 

This is the maximum run duration limit in minutes (a negative value 
is unlimited). This limit can terminate the solver before all steps are 
complete, which may be helpful if the solver is run as a batch system job 
with a time limit. Additional time is required to complete the current 
iteration and write restart hie. So, allow an extra time margin for code 
shutdown. MPI required. 

no_restart = .false. 

When this is .true., no restart checkpoint hie is written. 


= 500 
= l.e-15 
= - 1.0 
= .false. 
= 250 
= ' on ' 

= .true. 

= 0 
= 10 
= 0.10 
= 5.0 
= .false. 
= .false. 
= 50 
= 0.25 
= 180.0 
= -180.0 
= 0 

= .false. 
= 'ascii' 
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restart_write_f req = 250 

The restart checkpoint and convergence history files will be written to 
disk every restart_write_freq time steps of the current run. 

restart_read = ’on’ 

This defines the solution at the first time step. 

‘ on ’ to initialize the simulation with a solution read from the restart 
file. The current convergence history will be concatenated with the prior 
solution history. 

‘ onmohistorykept ’ to initialize the simulation with a solution read 
from the restart file. The previous history (e.g., residuals, forces, mo- 
ments) will be discarded. 

‘ of f ’ for no restart file read. The solution will be initialized as freestream 
or as specified in the &f low_initialization namelist. 

smart _j update = .true. 

This option allows the code to automatically adjust the Jacobian update 
frequency based on residual reduction. 

jacobian_eval_f req = 0 

This is the frequency of Jacobian evaluation based on time steps. It 
should be set to zero when smart _j update = .true. 

jupdate_startup_steps = 10 

The Jacobians are evaluated at every time step for the first jupdate_startup_steps, 
which aids robustness during initial start transients. 

jupdate_amut_max_change = 0.10 

For turbulent flow when the maximum eddy viscosity is greater than 1.5, 
the Jacobians are refreshed when the maximum eddy viscosity changes 
by this amount from the maximum eddy viscosity corresponding to the 
last jacobian evaluation. 

jupdate_cf l_inv_change = 5.0 

The Jacobians are refreshed when the time term associated with the cfl 
of the adaptive strategy and the time term of the last jacobian evaluation 
differ by this amount. 

dfduc3_jacobians = .false. 

This option only affects eqn.type = ’ incompressible ’ . When .true., 
approximate Jacobians are computed that may improve the convergence 
of some cases. 


144 



alpha_sweep = .false. 


This option activates a procedure to adjust angle.of .attack during a 
simulation. It can be used to calculate a drag polar in a single execution 
or explore a hysteresis loop. It is controlled by the following options. 

cycle.increment = 50 

When alpha_sweep=.true, 

cycle increment < 0 increments angle.of .attack after residuals have 
reached the stopping.tolerance. 

cycle increment > 0 is the number of iterations between increments 
to alpha. 

cycle increment = 0 is an inadmissible value. 
alpha_increraent = 0.25 

When alpha_sweep=.true., increment angle.of .attack by these many 
degrees at a point controlled by cycle.increment. 

alphannax = 180.0 

When alpha_sweep=.true., this is the maximum value of angle.of .attack. 
alpha_min = -180.0 

When alpha_sweep=.true., this is the minimum value of angle.of .attack, 
alpha.switchbacks = 0 

When alpha_sweep=.true., this is the number of directional changes in 
the angle.of .attack sweep. When alpha.switchbacks > o, alpha.increment 
changed in sign after reaching alphajmax or alphannin. This allows ex- 
ploration of hysteresis loops. 

write.steady .restart = .false. 

When write.steady _restart=. true., and running a time-accurate sim- 
ulation (itime\=0), this will cause a steady-state restart hie to be writ- 
ten, rather than an unsteady restart hie. This steady-state restart hie al- 
lows the steady-state solver to be used on subsequent executions. Warn- 
ing, solution time history will be discarded. 

sd_f ile_f ormat = ’ ascii ’ 

Specihes the format of mesh sensitivity hies. See section 9.3 for details, 
'ascii’ for ASCII formatted mesh sensitivity hies. 

' stream’ for Fortran-stream (C-binary) formatted mesh sensitivity hies. 
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B.4.14 ^nonlinear solver parameters 

This namelist defines the temporal accuracy of the solution advancement 
scheme. The subiterations and time step size of time accurate simulations 
can also be specified. The ramping of the pseudo time advancement CFL 
number is also set. Density and pressure floors on the update and relation 
factors are available. 


fenonl inear _solver_parameters 
time_accuracy 
time_step_nondim 
subiterations 
temporal_err_control 
temporal_err_f loor 
schedule_iteration(l : 2) 
schedule_cf 1 (1 : 2) 
schedule_cf lturb(l : 2) 
f _allow_minimum_m 
invis_relax_f actor 
visc_relax_f actor 
tight ly_couple 


1 steady ' 

0.0 

0 

.false . 

0.1 
1, 50 

200 . 0 , 200.0 
50.0, 50.0 
0.01 
1.0 
1.0 

.false . 


time.accuracy = ’steady’ 

This defines the temporal scheme. 

‘ steady’ for steady state calculations. This is a local time step pseudo- 
time advancement scheme that is not time accurate. 

‘ lstorder ’ is a first-order backward differencing scheme (backward Eu- 
ler) for time-accurate temporal time integration. 

‘ 2ndorder ’ is a second-order backward differencing scheme (BDF2 in 
[50]) for time-accurate temporal time integration. 

‘ 2ndorderOPT ’ is an optimized second-order backward differencing (BDF2opt 
in [51]) for time-accurate temporal time integration. This scheme is 
second-order accurate in time but has an order-of-magnitude lower lead- 
ing coefficient than standard BDF2. 

‘3rdorder’ is a third-order backward differencing scheme (BDF3 in 
[50]) for time-accurate temporal integration. 

‘ 4thorderMEBDF4’ is a fourth-order modified extended backward differ- 
encing scheme (MEBDF4 in [50]) for time-accurate temporal integration. 

‘ 4thorderESDIRK4’ is a fourth-order explicit, singly diagonally implicit 
Runge-Kutta (ESDIRK4 in [50]) for time-accurate temporal integration. 
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time_step_nondim = 0.0 


This is the nondimensional time step for time accurate simulations. 
It is ignored when time_accuracy = ’steady 5 . The nondimension- 
alization of this parameter depends on eqnvtype. When eqnvtype = 

5 compressible 5 , it is where a re / is the reference speed of sound, 

and L is unit 1 of the grid. When eqn.type = 5 incompressible 5 or 
’generic’, it is dt^-, where u re f is the reference velocity. See sec- 
tion 2.4 for more details and guidance on appropriate values. 

subiterations = 0 

Number of subiterations applied to solve the implicit time integration. 
It is ignored when time_accuracy = ’steady’. A constant CFL time 
step is used in each subiteration. By the end of a convergent subiteration 
process the pseudo time term drops out, giving the correct temporal 
discretization. 

temporal_err_control = .false. 

This governs whether the specified number of subiterations are run for 
each time step (.false.), or, if the temporal error is monitored and the 
subiterations are stopped when a specified tolerance is reached (.true.). 
It is ignored when time_accuracy = ’ steady’ . 

temporal_err_f loor =0.1 

This sets the tolerance for which time-accurate subiterations are stopped. 
The tolerance is given as a multiplicative factor of the flow residuals 
(mean and turbulence). It is ignored when time.accuracy = ’ steady’ . 

schedule_iteration(l : 2) = 1 , 50 

These are the iteration or subiteration numbers at which CFL numbers 
are specified. When time.accuracy = ’ steady’ , this controls the CFL 
number of the pseudo-time terms over iterations. When running tirne- 
accurately, this controls the CFL number of the pseudo-time terms of the 
linear system over subiterations. The parameter schedule_iteration(l) 
must be one, because it defines the starting CFL number at the first 
iteration or subiteration. The actual CFL number is determined by 
a linear ramp from schedule_cf 1 (1) at schedule_iteration(l) to 
schedule.cf 1 (2) at schedule_iteration(2) . The CFL number is held 
constant at schedule_cf 1 (2) after schedule_iteration(2) . 

schedule_cf 1 (1 : 2) = 200.0, 200.0 

This controls the ramping and final CFL number of the mea nfl ow equa- 
tions. See the description for schedule_iteration. 
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schedule.cf lturb(l : 2) = 50.0, 50.0 

This controls the ramping and final CFL number of the turbulence model 
equations. See the description for schedule_cf 1 in schedule_iteration. 

f _allow-minimum_m = 0.01 

This limits the solution update to prevent pressure and density from 
dropping below this fraction of their freestream values. Applied to 
eqn.type = ’ compressible ' only. 

invis_relax_f actor = 1.0 

This is the relaxation factor of inviscid terms. It scales the nonlinear 
update of the inviscid terms by this fraction and is only used for eqnrtype 
= 'generic 5 . 

visc_relax_f actor = 1.0 

This is the relaxation factor of viscous terms. It scales the nonlinear 
update of the viscous terms by this fraction and is only used for eqnrtype 
= 'generic'. 

tightly_couple = .false. 

Tightly couple the mean flow and turbulence equations during relaxation 
and nonlinear control of the solution update. Only supported for the 
sa-neg turbulence model. 
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B.4.15 &linear solver parameters 

The Fun 3D solution process involves constructing a linearization of the resid- 
ual with appropriate time terms and then solving this linear system to compute 
the solution update. This namelist controls the solution process of this linear 
system. The linearization is grouped in to the meanflow equations and the 
turbulence model equations. 

&linear_solver .parameters 
meant low_sweeps = 15 
turbulence_sweeps = 10 
linear_projection = .false. 
line_implicit = 'off' 

/ 

meanf low.sweeps = 15 

This is the number of the linear system red-black relaxations at each 
steady iteration or time step of the meanflow equations when there is no 
turbulence model or a loosely coupled turbulence model. For eqn.type 
= ’ generic’ or fully coupled meanflow and turbulence relaxation, this 
refers to all equations (meanflow and turbulence). 

turbulence_sweeps = 10 

This is the number of the linear system red-black relaxations at each 
steady iteration or time step of the turbulence equations, when the tur- 
bulence equations are loosely coupled. It has no effect for fully coupled 
mea nfl ow and turbulence relaxation or a simulation without a turbulence 
model. 

linear .projection = .false. 

This options uses a Krylov projection method generalized conjugate gra- 
dient (GCR) to stabilize and improve convergence of linear system. This 
will execute multiple sets of red-black relaxation to form the GCR search 
directions, until a convergence criteria is met. The only penalty to us- 
ing this option is increased execution time, which can be mitigated by 
reducing meanf low.sweeps. 

line.implicit = ’off’ 

This option selects the relaxation scheme. 

'off’ uses point implicit relaxation. 

‘ on’ uses line implicit relaxation where lines are defined and point relax- 
ation elsewhere. The line implicit feature requires construction of these 
lines prior to running Fun 3D. The lines are stored in the a file named 
[project_rootname] .lines.fmt, see section 4.4 for a description. The 
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af lr3_line_extraction utility is distributed with Fun 3D to generate 
these lines. 
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B.4.16 ^elasticity gmres 

This namelist controls the GMRES [52] algorithm used to solve the linear 
elasticity equations that govern mesh deformation. GMRES is currently the 
only solver used for the linear elasticity equations. If negative volumes are 
produced during mesh movement, decreasing the tol may prevent mesh move- 
ment failure. Increasing nrestarts or nsearch make it possible to reach tol 
for problems that do not converge with default settings. 

&elasticity_gmres 
nsearch = 50 
nrestarts = 10 
tol = l.e-6 

/ 


nsearch = 50 

Number of GMRES search directions. Memory requirements increase 
linearly with nsearch. 

nrestarts = 10 

Maximum number of restarts allowed when attempting to solve the sys- 
tem of equations to the specified tol. 

tol = l.e-6 

Convergence tolerance for solving the linear system. A better con- 
verged linear system (lower tol) may produce deformed grids with better 
shaped elements (less likely to have negative volumes). 
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B.4.17 ^boundary conditions 


This namelist provides auxiliary information to the boundary conditions. Re- 
fer to section 3 for the definition of boundary numbers and other information. 


&boundary_conditions 

total_pressure_ratio ( : ) 

total_temperature_ratio( : ) 

subsonic_inf low_velocity ( : ) 

alpha_bc ( : ) 

beta_bc( : ) 

thetal ( : ) 

theta2 ( : ) 

theta3( : ) 

pt_amplitude ( : ) 

pt_f requency ( : ) 

pt_phase( : ) 

tt_amplitude ( : ) 

tt_f requency ( : ) 

tt_phase( : ) 

ampl ( : ) 

freq( : ) 

phase ( : ) 

random ( : ) 

ramp_constant ( : ) 

start_time ( : ) 

duration( : ) 

surge_amplitude ( : ) 

pressure_relaxation( : ) 

engine_ref erence_length 

engine_symmetry ( : ) 

npr_set 

static_pressure_ratio ( : ) 
mach_bc( : ) 
massf low( : ) 
grid_units 
q_set ( : , 1 : 5) 
q_set_ramp( : ) 
prof ile_type ( : ) 
patch_center ( : ,1:3) 
patch_scale ( : ) 
prof ile_rho_coef ( : ,0:6) 
prof ile_u_coef ( : ,0:6) 
prof ile_p_coef ( : ,0:6) 
prof ile_coef ( : ,1:3) 
wall_velocity ( : ,1:3) 


= 1.0 
= 1.0 
= 'normal' 

= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= .false. 

= 1.0 
= 0.0 
= 0.0 
= 0.0 
= 1.0 
= 1.0 
= 1.0 
= 0.0 
= 1.0 
= 0.0 
= 0.0 
= 'nondim' 

= 0.0 
= 0 

= ' radial_polynomial ' 
= 0.0 
= 1.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
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rotation_center ( : ,1:3) 
rotation_vector ( : ,1:3) 
rotation_rate ( : ) 
unorm_bc( : ) 
wall_temperature ( : ) 
wall_temp_f lag( : ) 
wall_radeq_f lag( : ) 
wall_emissivity ( : ) 
wall_emissivity_b( : ) 
wall_emissivity_c ( : ) 
wall_emissivity_d( : ) 
wall_temp_relax( : ) 
wall_catalysis_model ( : ) 
catalytic_eff iciency_o( : ) 
catalytic_eff iciency_n( : ) 
ablation_option_map( : ) 
ablation_recession 
ablation_recession_freq 
st art _re cession 
bprime_f lag_map ( : ) 
compute_mdot_initial_map ( : ) 
f req_mdot_map ( : ) 
f req_wall_map ( : ) 
uncoupled_ablation_f lag_map( : ) 
wall_blowing_model ( : ) 
virgin_density_wall ( : ) 
char_density_wall ( : ) 
CHONSi_frac_char_map( : ,1) 
CHONSi_frac_pyrolysis_map( : , 1) 
h_ablation_map( : , : ) 
indot _pres sure _map ( : , : ) 
t_sublimation_map ( : , : ) 
plenum_tO( : ) 
plenum_pO( : ) 
plenum_id( : ) 
f ixed_in_id( : ) 
f ixed_in_rho ( : ) 
f ixed_in_uvw( : , 1 : 3) 
f ixed_in_t ( : ) 
f ixed_in_tv( : ) 
f ixed_in_turb( : ,1:7) 
specif ied_transition( : ) 
impose_pressure_gradient 
pressure_gradient ( : ) 
x_constant_boundary ( : ) 


= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 1.0 
= .false. 

= .false. 

= 0.8 
= 0 . 

= 0. 

= 0 . 

= 0.001 

= 'super-catalytic' 
= 0 . 

= 0 . 

= 0 

= .false. 

= 3000 
= 0 
= 1 
= 1 

= 5000 
= 50 
= 0 

= 'none' 

= 1 . 

= 1 . 

= 1 . 

= 1 . 

= 0. 

= 0. 

= 0. 

= 1000 . 

= 1000 . 

= 0 
= 0 
= 0. 

= 0. 

= 0. 

= 0. 

= 0. 

= .false. 

= .false. 

= 0.0 
= .false. 
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y_constant_boundary ( : ) 
z_constant_boundary ( : ) 
tol_const_ coord 


.false . 
.false . 
1.0e-6 


/ 

total_pressure_ratio ( : ) = 1.0 

This is the ratio of plenum total pressure to reference pressure used by 
7011 boundary condition. Inflow Mach number must be less than one. 

total_temperature_ratio ( : ) = 1.0 

This is the ratio of plenum total temperature to reference temperature 
used by 7011 boundary condition. Inflow Mach number must be less 
than one. 

subsonic.inf low_velocity ( : ) = ’normal 1 

This sets the direction of the inflow velocity. 

‘ normal ’ for inflow normal to each element face in the patch 

'alpha, beta’ the angle of the inflow is specified by alphaibc and 
betaibc as shown in Fig. 4. 

'interior’ the angle of the inflow is specified by the Euler angles 
thetal, theta2, and theta3 as shown in Fig. B5. 

'offset’ the angle of normal inflow to the patch boundary is rotated 
by the Euler angles thetal, theta2, and theta3 as shown in Fig. B5. 

alpha_bc(:) = 0.0 

When subsonic_inf low_velocity = ’ alpha, beta’ , this is the angle 
of attack in radians for 7011 boundary condition inflow. 

beta_bc(:) = 0.0 

When subsonic_inf low_velocity = ’ alpha, beta’ , this is the angle 
of sideslip in radians for 7011 boundary condition inflow. 

thetal(:) = 0.0 

When subsonic_inf low_velocity = ’interior’ or ’offset’, this is 
the Euler angle 6 in radians for 7011 boundary condition inflow. 

theta2(:) = 0.0 

When subsonic_inf low_velocity = ’interior’ or ’offset’, this is 
the Euler angle (p in radians for 7011 boundary condition inflow. 

theta3(:) = 0.0 

When subsonic_inf low_velocity = ’interior’ or ’offset’, this is 
the Euler angle ip in radians for 7011 boundary condition inflow. 
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pt_amplitude ( : ) = 0.0 

For use with the 7011 boundary condition, this sets the amplitude of 
pulsed total pressure. ampl*sin(freq*simulation_time+phase*pi/180). 

pt_frequency ( : ) = 0.0 

For use with the 7011 boundary condition, this sets the frequency of 
pulsed total pressure, see ampl. 

pt_phase(:) = 0.0 

For use with the 7011 boundary condition, this sets a phase shift (in 
degrees) of the inflow total pressure values, see ampl. 

tt_amplitude( : ) = 0.0 

For use with the 7011 boundary condition, this sets the amplitude of 
pulsed total temperature conditions. 

tt_frequency ( : ) = 0.0 

For use with the 7103 boundary condition, this sets the frequency of 
pulsed total temperature, see ampl. 

tt_phase(:) = 0.0 

For use with the 7011 boundary condition, this sets a phase shift (in 
degrees) of the inflow total temperature, see ampl. 

ampl(:) = 0.0 

For use with the 7103 boundary condition, this sets the amplitude of 
pulsed inflow conditions. Only the velocity is varied using the equation 
[u,v,w\ = ampl*sin(freq*simulation_time+phase*pi/180). 

freq(:) = 0.0 

For use with the 7103 boundary condition, this sets the frequency of 
pulsed inflow velocity values, see ampl. 

phase(:) = 0.0 

For use with the 7103 boundary condition, this sets a phase shift (in 
degrees) of the inflow velocity values, see ampl. 

random(:) = .false. 

For use with the 7103 boundary condition, this creates random fluctua- 
tions in in the magnitude of the supersonic inflow conditions in the range 
[0,ampl] when .true.. 
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ramp.constant ( : ) = 1.0 


For use with 7104 boundary condition, this ramps the velocity magnitude 
of supersonic inflow conditions with the exponential expression, (1 — 
exp(— simulation_time/ramp_constant)). 

start_time ( : ) = 0.0 

For use with the 5060 boundary condition, this is the start time, in terms 
of Fun3D simulationvtime, of a delta function change to the subsonic 
outflow static pressure ratio. 

duration(:) = 0.0 

For use with the 5060 boundary condition, this sets the duration of the 
delta function change in units of Fun3D time, see simulation_time. 

surge_amplitude ( : ) = 0.0 

For use with the 5060 boundary condition, this sets the transient increase 
in the value of the outflow static pressure ratio as a percentage of the 
base line value. For example, a 2 percent transient applied to block 5 is 
input as surge_amplitude (5) = 2.0. 

pressure_relaxation( : ) = 1.0 

For use with the 5051 boundary condition, this weights the user specified 
back pressure with the solution pressure, p .applied = pressure_relaxation 
* static.pressurexratio + ( 1 - pressurexrelaxation ) * pressure.internal 

enginexref erence.length = 1.0 

Use this factor to scale the non-dimensional time in the engine simulation 
package. 

engine.symmetry ( : ) = 1.0 

Use this factor to scale the area and massflow of an engine. This factor 
is used in the physical engine modeling routines, so that the actual mass- 
flow numbers can be tracked properly. For example, set to 2.0 for an inlet 
face on a symmetry plane or set to 360.0 for a one-degree axisymmetric 
wedge. 

npr.set = 0.0 

This sets the nozzle pressure ratio for nozzle component performance. 

static_pressure_ratio( : ) = 1.0 

This is the ratio of specified boundary static pressure to reference pres- 
sure used by the 7012 and 5051 boundary conditions. Outflow Mach 
number must be less than one. 
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mach_bc(:) = 0.0 

This is Mach number on boundary face used by 5052 and 7031 boundary 
conditions. Outflow Mach number must be less than one. 

massflowQ) = 0.0 

This is massflow through boundary face in units of grid unit squared 
used by 7031 and 7036 boundary conditions. It is nondimensionalized 
according to (pooOoo) for eqn_type = ’ compressible J . 

grid_units = ’nondim’ 

This converts a user specified dimensional massflow to units of mesh unit 
squared. If massflow is input in units of mesh units squared, grid_units 
is not required. 

‘ nondim ’ for nondimensional input 

‘ in ’ for meters 

‘ cm ’ for centimeters 

‘ mm ’ for millimeters 

‘feet’ for feet 

‘ inches ’ for inches 

q_set ( : , 1 : 5) = 0.0 

This sets the primitive variables on boundary face used by boundary 
conditions 7100 and 7105. 

q_set_ramp( : ) = 0 

When this is greater than zero, primitive variables on boundary face are 
ramped from zero to q_set over these iterations, for boundary conditions 
7100 and 7105. 

prof ile_type ( : ) = ’ radial.polynomial ’ 

This switches between inflow profiles, 

‘ radial_polynomial ’ defines a radial polynomial about patch_center 

of size patch_scale with prof ile_rho_coef , prof ile_u_coef , and prof ile_p_coef . 

‘ power.law ’ defines a power-law velocity profile function with prof ile.coef . 

patch_center ( : , 1 : 3) = 0.0 
This is the center of a 7101 be. 
patch_scale( : ) = 1.0 
This scales the radius of a 7101 be. 
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prof ile_rho_coef ( : , 0 : 6) = 0.0 

This is the radius polynomial coefficients of density for 7101 be. 
prof ile_u_coef ( : , 0 : 6) = 0.0 

This is the radius polynomial coefficients of u for 7101 be. 
prof ile_p_coef ( : , 0 : 6) = 0.0 

This is the radius polynomial coefficients of pressure for 7101 be. 
prof ile_coef ( : , 1 : 3) = 0.0 

These three coefficients are wind speed reference, reference height, and 
power law exponent, 

prof ile_coef ( : , 1) * (z/prof ile_coef ( : , 2) ) **prof ile_coef ( : , 3) 
wall_velocity( : , 1 : 3) = 0.0 

This is the 4000 solid wall specified translational velocity. It should be 
tangent to the boundary to ensure a well-posed problem. 

rotation.center ( : , 1 :3) = 0.0 

This is the 4000 solid wall specified rotational velocity center point, see 
rotationweetor and rotationrrate. 

rotation.vector ( : , 1 :3) = 0.0 

This is the 4000 solid wall specified rotational vector, see rotation_center 
and rotation_rate. Should be unit length. 

rotation_rate( : ) = 0.0 

This is the 4000 solid wall specified rotational rate in reference speed of 
sound per grid unit (eqn_type = ’ compressible ’ ) or reference speed 
per grid unit (eqn_type = ’ incompressible ’) (cv — cj *— — ^ — or u = 

a ref -‘-'ref 

L* 

u)*Tr t — - — ), see rotation_center. rotation.vector, and section 2. 

v ref^ref n 

unorm_bc( : ) = 0,0 

This is the specified velocity in the boundary normal direction, for 4000 
solid walls. 

wall_temperature( : ) = 1.0 

This is the ratio of wall temperature to reference temperature for eqnrtype 
= ’ compressible ’ or the wall temperature in degrees Kelvin for eqnrtype 
= ’generic’. If set to -1, then the wall temperature is computed so 
that there is zero heat flux, i.e. , adiabatic. The wall_temp_f lag must 
be set to .true, for this boundary condition to take effect. 
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wall_temp_f lag( : ) = .false. 

This must be .true, when specifying the wall temperature via the namelist 
variable wall_temperature. The default .false, sets Tpy = 1+ 
for eqnvtype = ’ compressible ’ , see Anderson and Bonhaus [2], 

wall_radeq_f lag( : ) = .false. 

Compute the wall temperature via the Stefan-Boltzmann Law. The ra- 
diative equilibrium wall temperature is computed from the heating rate 
Qwaii using q wa u = eaT^ adeq where the surface emissivity e is entered as 
wall.emissivity and cr is the Stefan-Boltzmann constant. 

wall.emissivity ( : ) = 0.8 

This is 6q, where emissivity is specified as a function of wall temperature 
with the expression e = e 0 + T(e& + T(e c + Ted)). The other coefficients 
are entered via the following three variables. 

wall_eraissivity_b( : ) = 0. 

This is 6b in the above equation. 

wall.emissivity.c ( : ) = 0. 

This is e c in the above equation. 

wall_emissivity_d( : ) = 0. 

This is €d in the above equation. 

wall.temp .relax ( : ) = 0.001 

This is the relaxation factor rj used for wall_radeq_f lag wall tempera- 
ture boundary condition. The wall temperature is updated as T new = 
T old + rj * (T radeq - T old ) 

wall.catalysisjnodel ( : ) = ’ super-catalytic 5 

This defines the catalytic efficiency of the wall to promote recombination 
of atoms to molecules. Allowable options are: 

‘ super-catalytic ’ Forces the mass fraction of species at the wall to 
equal the mass fractions specified for the free stream in the tdata hie. 

‘ fully-catalytic ’ Specifies a catalytic efficiency of 1 thereby forcing 
homogeneous recombination of atoms diffusing to the wall. 

‘ non-catalytic ’ Specifies a zero mole fraction gradient at the wall - 
signifying zero catalytic efficiency. 

‘ equilibrium-catalytic ’ Computes the equilibrium chemical compo- 
sition of species at the wall temperature and pressure. 
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‘ constant-catalytic’ Catalytic efficiency is user specified constants 

‘ Stewart-RCG’ Reaction cured glass from Stewart 

‘Zoby-RCG’ Reaction cured glass from Zoby 

‘Scott-RCG’ Reaction cured glass from Scott 

‘CSiC’ Experimental CSiC from JSC for X-38 

‘ RCC-LVP ’ Stewart NASA TM 112206 

‘CCAT-ACC’ Shuttle RCC from Stewart NASA TM 112206 

‘CSiC-SNECMA’ Derived from Stewart RCC 

catalytic.ef f iciency_o ( : ) = 0. 

This is the fraction of diffusion flux of atomic oxygen striking wall 
that is converted to molecular oxygen, when wall_catalysis unodel = 
’ constant-catalytic ’ . 

catalytic.ef f iciency_n( : ) = 0. 

This is the fraction of diffusion flux of atomic nitrogen striking wall 
that is converted to molecular nitrogen, when wall_catalysis unodel = 
’ constant-catalytic ’ . 

ablation_option_map( : ) = 0 

This is an integer that specifies whether the pyrolysis ablation rate and 
wall temperature are computed in addition to the char ablation rate. 
This option only affects cases with bprime_f lag_map equal to 0 or 1. 

‘ 0 ’ The pyrolysis ablation rate and wall temperature are computed, in 
addition to the char ablation rate, assuming steady-state ablation. 

‘ 1 ’ The pyrolysis ablation rate and wall temperature are held constant 
(they are set to the values present in ablation.f rom_laura.m) while the 
char ablation rate is computed. 

ablation_recession = .false. 

This flags triggers the surface deformation and mesh movement through 
aeroclastic deformation. Note: this flags only applies to the internal 
Fun3D coupled-ablation mechanism and is not applicable to Fun3d- 
CHAR coupled ablation. Default: .false. 

ablation_recession_freq = 3000 

It is an integer that specifies the frequency of surface recession up- 
date. This flags only works with ablation_recession = .true.. De- 
fault: 3000 
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start_recession = 0 

It is an integer that specifies when to start applying recession for surface 
deformation. Default: 0 

bprime_f lag_map( : ) = 1 

This is an integer defining if the b-prime approach is applied. Applicable 
only for blowing model equil_char_quasi_steady = 0. 

‘ 0 J Do not use bprime approach, and instead use a rigorous diffusion 
model. This option is consistent with the ’’Fully-Coupled” approach 
defined in Ref. [2], 

‘ 1 J Use b-prime approach. This option is consistent with the ’’Partially- 
Coupled” approach defined in Ref. [2], 

‘ 2 J Hold the ablation rate and wall temperature constant from the 
restart file, while applying the rigorous diffusion model (thus, the surface 
energy balance and char equilibrium constraint are not satisfied). This 
option is sometimes useful when transitioning from a bprime flag = 1 
computation to a bprime flag = 0 computation. 

compute_mdot_initial_map( : ) = 1 

This is an integer defining if the ablation rates are computed before the 
first flowfield iteration. 

‘ 0 J Applies the ablation rates and wall temperatures present in the 

ablation.f rom_laura.m file. 

‘ 1 J Computes the ablation rates and wall temperatures before the first 
flowfield iteration. 

frequndotunapC : ) = 5000 

For bprime_f lagunap = 1, this is an integer defining frequency of up- 
dating ablation rates and wall temperature. 

freq.wall unap( : ) = 50 

For bprime_flag = 1, this is an integer defining frequency of update 
to ablation wall boundary conditions. For bprime_flag = 0, an inte- 
ger defining frequency of update to the surface energy balance solution, 
which defines the wall temperature. 

uncoupled_ablation_flag_map( : ) = 0 

This is an integer defining if an uncoupled ablation analysis is applied. 
The uncoupled ablation option is included to provide a baseline solution 
for the coupled ablation analysis. 

‘ 0 J Do not apply an uncoupled ablation analysis. 
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‘ 1 ’ Apply an uncoupled ablation analysis to a converged non-ablating 
flowfield. 

wall_blowing_model( : ) = ’none’ 

This is the blowing or ablation model. 

‘ none ’ No wall blowing 

‘ specified’ blowing rate is user specified function of pressure (see also 
mdot.press) 

‘ porous_chamber ’ Special options for simulation of buoyancy driven 
flow in pressurized rig for BNNT production 

‘ quasi.steady ’ Compute ablation rate as function of surface energy 
balance and equilibrium catalytic be 

‘ equil_char_quasi_steady ’ Include equilibrium char approximation 
'FIAT’ Couple to material response code FIAT (not active) 

virgin_density_wall ( : ) = 1. 

This is the density (kg/m 3 ) of thermal protection system ablator in virgin 
state (prior to heating level sufficient to cause any reactions). 

char_density_wall ( : ) = 1. 

This is the density (kg/m 3 ) of remaining char in ablator after binding 
resins have pyrolized. 

CHONSi_frac_char_map( : , 1) = 1- 

See definition below for CH0NSi_f racypyrolysis unap 
CHONSi_frac_pyrolysis_map( : , 1) = 1. 

These arrays set elemental mass fraction (second index) of C, H, O, N, 
Si, Fe, Mg, Na, B species for char and pyrolysis gas. The fractions in 
each array should sum to 1. 

h_ablationunap( : , : ) = 0. 

This is a vector of extent 3 used to compute the heat of ablation in M J /kg 
for quasi steady blowing option as h_ablation_0(l) + (h_ablation_0 (2) 
) log pw + (h_ablation_0 (3) ) (log pw) * *2 where pw is the local 
pressure, in atmospheres. 

mdot_pressure_map( : , : ) = 0. 

This is a vector of extent 2 is used to set the blowing or suction dis- 
tribution defined as mdot_pressure_0(l) + (mdot_pressure_0(2))*p/ 
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(rhcvinf *V_inf **2) where p is the local pressure, rho_inf is the refer- 
ence density, and V_inf is the reference velocity. Positive value produces 
blowing distribution, while negative value produces suction distribution. 

t_sublimation_map( : , : ) = 0. 

This is a vector of extent 3 used to compute the sublimation temperature 
in degrees Kelvin for quasi steady blowing option as t_sublimation_0 (1) 

+ (t_sublimation_0(2) ) log pw + (t_sublimation_0 (3) ) (log pw) 
**2 where pw is the local pressure, in atmospheres. 

plenum_t0( : ) = 1000. 

For use with the 7021 boundary condition, this is the total plenum tem- 
perature in Kelvin. 

plenum_p0( : ) = 1000. 

For use with the 7021 boundary condition, The total plenum pressure in 
N/m 2 (Pascals) feeding this boundary. 

plenum_id( : ) = 0 

For use with the 7021 boundary condition (one or more rcs_jet plenum 
bcs), the jet plenum contains this species set from the hie tdata. For 
example, if an RCS jet is bring H 2 and 0 2 into an air stream, the tdata 
hie may look like: 

One Temperature 
N 
0 

N2 0.76 
02 0.24 
NO 

H2 0.5 
02 0.5 
OH 
H 
0 

In this case, if the boundary to the plenum is surface number 5 then 
plenum_id(5)=2, the second grouping of species in the tdata hie. The 
numbers following the species name define the mass fraction of that 
species at the inhow boundary. The sum of the mass fraction in each 
group must equal one. Species groups are separated by blank lines and 
multiple RCS jets may be defined in this manner. 
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f ixed_in_id( : ) = 0 


For use with the 70XX boundary condition (one or more supersonic 
inflow bcs) the supersonic inflow boundary condition contains the species 
set in the same way as the plenum_id for the rcs.jet plenum boundary 
condition described above 

f ixed_in_rho ( : ) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inflow bcs) the dimensional inflow mixture density in kg/m* *3 

f ixed_in_uvw( : , 1 : 3) = 0. 

For use with the 70XX boundary condition (one or more supersonic in- 
flow bcs) the dimensional inflow Cartesian velocity components in m/sec 

f ixed_in_t ( : ) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inflow bcs) the dimensional inflow translational rotational temperature 
in Kelvin 

f ixed_in_tv( : ) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inflow bcs) the dimensional inflow vibrational-electronic temperature in 
Kelvin 

f ixed_in_turb( : , 1 : 7) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inflow bcs) This is for the turbulence models for a one-equation model 
this is the ratio of the inflow eddy viscosity to the inflow molecular 
viscosity, for a two-equation model this is: the inflow turbulence intensity 
and the ratio of the inflow eddy viscosity to the inflow molecular viscosity 
Full Reynolds stress models are not currently supported 

specif ied_transition( : ) = .false. 

When .true., a turbulent transition point will be imposed on the solu- 
tion. 

impose_pressure_gradient = .false. 

When .true., a global pressure gradient in the direction of pressure_gradient 
will be imposed as a source term to the residual. 

pressure.gradient ( : ) = 0.0 

The nondimensional pressure gradient in Cartesian coordinates, imposed 
when impose_pressure_gradient = .true. 
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x_c onst ant .boundary (: ) = .false. 

This specifies that a boundary is an x constant face for mesh movement, 
constraining motion the to be tangent to face. Set automatically for 
^-symmetry boundaries. 

y_c onst ant .boundary (: ) = .false. 

This specifies that a boundary is an y constant face for mesh movement, 
constraining motion the to be tangent to face. Set automatically for 
^/-symmetry boundaries. 

z-constant-boundary ( : ) = .false. 

This specifies that a boundary is an z constant face for mesh movement, 
constraining motion the to be tangent to face. Set automatically for 
2 -symmetry boundaries. 

tol-const-coord = 1.0e-6 

This is the tolerance for verifying that a boundary surface is a planar 
boundary for mesh movement by restricting the minimum and maximum 
value in the “constant” direction. 
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B.4.18 ^periodicity 


This namelist contains variables that specify inputs relevant to periodic bound- 
ary conditions. 

&periodicity 

periodic_dir (1 : 3) = 0 
periodic_tol = l.e-10 

/ 


periodic.dir (1 : 3) = 0 

This integer array specifies the Cartesian coordinate direction associ- 
ated with each periodic boundary face pair in the simulation. The 
periodic.dir (1) entry is for faces marked with the 6100 boundary con- 
dition. The periodic_dir (2) entry is for 6101 and periodic.dir (3) 
is for 6102. For example, if a single pair of boundaries have periodicity, 
they should be given the 6100 boundary condition and periodic_dir (1) 
should reflect the desired Cartesian direction of periodicity. 

‘ 0 J when this periodic boundary pair is not used. 

‘ 1 J when this periodic boundary pair is normal to the x-Cartesian di- 
rection. 

‘ 2 J when this periodic boundary pair is normal to the ^/-Cartesian di- 
rection. 

‘ 3 J when this periodic boundary pair is normal to the ^-Cartesian di- 
rection. 

periodic.tol = l.e-10 

Tolerance on determining coincident points on periodic boundary pairs. 
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B.4.19 fetwo d trans 

This namelist is used to specify a 2D transition location. If the airfoil is split 
into upper and lower patches, the transition location can be specified indepen- 
dently on each patch. If there is only a single patch, it can be split with a z 
value to designate the upper and lower airfoil surfaces. This transition specifi- 
cation is limited to specifying transition on a single-element configuration such 
as an airfoil or a flat plate. Only a single transition location is supported for 
multi-element airfoils. Transition is modeled by turning off the turbulent pro- 
duction terms in “laminar” regions of the grid. This option is only valid for the 
perfect gas SA turbulence model. This is the same approach taken in CFL3D 
and NSU3 D.Fun 3D results from this approach for a DLR-F6 transonic cruise 
condition are shown in Lee-Rausch et al. [53] 

&two_d_trans 

turb_transition 
use_2d_values 
upper_patch 
lower_patch 
use_z_value 
z_location 
upper _x_lo cat ion 
lower_x_location 

/ 

turb_transition = .false. 

This must be .true, to specify laminar regions of flow during a turbulent 

flow simulation. 

use_2d_values = .false. 

This enables 2D transition specification. 

upper _patch = 1 

This is the upper patch with specified transition. 

lower_patch = 1 

This is the lower patch with specified transition. 

use_z_value = .false. 

This allows a single patch to be split into upper and lower surfaces of an 

airfoil by a z plane. 

z_location = 0.0 

This is the z location to split the airfoil if use_z_value = .true. 


= .false. 
= .false. 
= 1 
= 1 

= .false. 
= 0.0 
= 0.0 
= 0.0 
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upper_x_location = 0.0 

This is the upper surface x transition location. 

lower_x_location = 0.0 

This is the lower surface x transition location. 
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B.4.20 &three d trans 

This namelist is used to specify 3D boundary layer transition locations. The 
command line option — turb.transition is required to activate. If you run 
the flow solver without the — turb.transition, it will default to fully tur- 
bulent even though you have the laminar boundaries defined. Transition is 
modeled by the turning off the turbulent production terms in “laminar” re- 
gions of the grid. This option is only valid for the perfect gas SA turbulence 
model. This is the same approach taken in CFL3D and NSU3 D.Fun 3D re- 
sults from this approach for a DLR-F6 transonic cruise condition are shown 
in Lee- Rausch et al. [53] 

&three_d_trans 
use_3d_values 
n_transition_group 
transition_group_patches ( : ) 
transition_xl ( : ) 
transition_yl ( : ) 
transition_x2 ( : ) 
transition_y2 ( : ) 

/ 

use_3d_values = .false. 

This turns 3D transition specification on. 
n_transition_group = 1 

This is the number of patch groups, limited to 100. 
transition_group_patches ( : ) = ’ 1 ’ 

This is the patch indexes for each group. Commas and dashes can be 
used to specify ranges, i.e., ’1,2, 5-7 ’ . 

transitionxxl ( : ) = 0.0 

This is the x value for determining the start of the transition line. 
transition_yl ( : ) = 0.0 

This is the y value for determining the start of the transition line. 
transition_x2( : ) = 0.0 

This is the x value for determining the end of the transition line. 
transition_y2( : ) = 1.0 

This is the y value for determining the end of the transition line. 


= .false. 
= 1 
= ' 1 ' 

= 0.0 
= 0.0 
= 0.0 
= 1.0 


169 



B.4.21 feflow initialization 

This namelist allows the user to initialize regions of the meanflow solution with 
quantities other than freestream. A maximum of 100 volumes can be defined. 
The volumes may overlap each other as well as domain boundaries. In the event 
that a grid point is contained in more than one volume, a subsequent volume 
in this hie will supersede the volumes listed before it. Boundary conditions 
supersede the how initialization. 


&flow_ initialization 


number _of_volumes 

= 

0 

type_of _volume ( : ) 

= 

1 none 1 

center(l :3, : ) 

= 

0.0 

radius ( : ) 

= 

0.0 

pointl (1 : 3 , : ) 

= 

0.0 

point2 (1 : 3 , : ) 

= 

0.0 

radius 1 ( : ) 

= 

0.0 

radius2( : ) 

= 

0.0 

rho ( : ) 

= 

1.0 

c ( : ) 

= 

1.0 

u( : ) 

= 

0.0 

v( : ) 

= 

0.0 

w( : ) 

= 

0.0 

mass_f raction( : , : ) 

= 

l.e-20 

temperature ( : , : ) 

= 

1000. 


/ 

number_of ..volumes = 0 

This is the number of initialization volumes. 

type_of wolume ( : ) = ’none’ 

This is the type of initialization volume. 

'box’ for a box. The diagonal corners are specihed by point 1 and 
point2. 

‘ sphere ’ for a sphere. The position and size is specihed by center and 
radius. 

'cylinder’ for a cylinder with size radius. The center axis is defined 
between pointl and point 2. 

' cone ’ for a cone or frustum. The center axis is defined between pointl 
and point2. Two radii are required, radius 1 at pointl and radius2 
at point2. A frustum is specihed with two nonzero radii. 

center(l : 3, : ) = 0.0 

This is the center of the ’ sphere ’ volume type. 
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radius(:) = 0.0 


This is the radius of the ’ sphere’ and ’ cylinder’ volume types, 
pointl (1 : 3, : ) = 0.0 

This is one end of the ’ cone ’ or ’ cylinder’ volume types or one corner 
of a ’box’ volume type. 

point2(l : 3, : ) = 0.0 

This is the other end of the ’ cone’ or ’ cylinder’ volume types or the 
opposite corner of a ’box’ volume type. 

radiusl(:) = 0.0 

This is the radius at pointl of ’ cone’ volume type. 
radius2(:) = 0.0 

This is the radius at point2 of ’ cone’ volume type. 
rho(:) = 1.0 

This is the nondimensional density in the volume. 
c ( : ) = 1.0 

This is the nondimensional speed of sound in the volume. 
u( : ) = 0.0 

This is the nondimensional ^-component of velocity in the volume. 
v( : ) = 0.0 

This is the nondimensional ^-component of velocity in the volume. 
w( : ) = 0.0 

This is the nondimensional ^-component of velocity in the volume. 
mass_fraction( : , : ) = l.e-20 

This is the species mass fraction array in the volume. The maximum 
number of species (first index) is hardwired to 50 in this namelist. The 
second index is the volume index. All mass fractions are initialized to 
trace values (l.e-20) so it is only necessary to define non-trace species. 
This option only applies to eqn_type=’ generic’ . 

temperature ( : , : ) = 1000. 

This is the translational-rotational and vibrational electronic tempera- 
ture array in the volume, in units of Kelvin. First index is 1 for the 
translational-rotational temperature and 2 for the vibrational-electronic 
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temperature. The second index is the volume index. This option only 
applies to eqn_type =:i generic ’ . 
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B.4.22 fecomponent parameters 


This namelist provides expanded ability to track forces, moments, and mass- 
flows according to user-specified groups of boundary patches that define a 
“component.” 


&component_parameters 
component_symmetry ( : ) 
number _of_ components 
component_count ( : ) 
component_xmc ( : ) 
component_ymc ( : ) 
component_zmc ( : ) 
component_cref ( : ) 
component_bref ( : ) 
component_sref ( : ) 
component_hinge_sweep( : ) 
component_hinge_dihedral ( : ) 
component_input ( : ) 
component_name ( : ) 
calculate_cd( : ) 
calculate_thrust_ratio( : ) 
massf low_component ( : ) 
throat_area( : ) 
npr ( : ) 
ntr ( : ) 

allow_f low_through_f orces 


1.0 

0 

0 

x_moment_ center 
y_moment_ center 
z_moment_ center 
x_moment _ length 
y _moment _ length 
ref erence_area 
0.0 

0.0 
I I 

I I 

.false . 

.false . 

0 

0.0 

0.0 

0.0 

.false . 


component _symmetry( : ) = 1.0 

The factor to multiply existing mesh surface by to obtain the complete 
area. For example, if only 1/4 revolution of an axisymmetric nozzle is 
modeled, component .symmetry (ib) should be set to 4.0. 


number _of .components = 0 

This is the number of components (groups of boundary patches) to track. 


component.count ( : ) =0 

This is the number of boundary patches assigned to a component. If -1 
is given, this number is computed implicitly from component.input. 

component_xmc( : ) = x_moment_center 

This is ^-coordinate of the moment center assigned to a component. The 

default value comes from the force and moment namelist, &f orce _moment_integ_properties. 
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component_ymc( : ) = y_moment_center 

This is ^/-coordinate of the moment center assigned to a component. The 

default value comes from the force and moment namelist, &f orce_moment_integ_properties. 

component_zmc( : ) = zunoment.center 

This is z-coordinate of the moment center assigned to a component. The 

default value comes from the force and moment namelist, &f orce_moment_integ_properties. 

component _cref ( : ) = x_moment_length 

This is the ^-direction reference length assigned to a component used to 
non-dimensionalize moments about y (pitching moment). The default 
value comes from the force and moment namelist &f orce_moment_integ_properties. 

component _bref ( : ) = y_moment_length 

This is the ^/-direction reference length assigned to a component used to 
non-dimensionalize moments about x (rolling moment) and z (yawing 
moment). The default value comes from the force and moment namelist 
&f orce_moment_integ_properties. 

component.sref ( : ) = ref erence_area 

This is the reference area assigned to a component used to non-dimensionalize 
forces and moments. The default value comes from the force and moment 
namelist &f orce_moment_integ_properties. 

component _hinge_sweep( : ) = 0.0 

This is the hinge sweep angle in degrees assigned to a component used 
to non-dimensionalize moments about y (pitching moment). The default 
value is zero. 

component_hinge_dihedral ( : ) = 0.0 

This is the hinge dihedral angle in degrees assigned to a component used 
to non-dimensionalize moments about x (rolling moment). The default 
value is zero. 

component .input ( : ) = ’ ’ 

This is the list of boundary patches to assigned to a component. Bound- 
ary indexes are separated with commas and dashes can be used to specify 
ranges, i.e., ’1,2, 5-7’. 

component .name ( : ) = 1 ’ 

This is the component output filename, [pro j ect_rootname] _fm_ [component .name] 

.dat. 
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calculate_cd( : ) = .false. 

This will request an ideal mass flow calculation for component n. 
calculate_thrust_ratio ( : ) = .false. 

This will request a thrust ratio calculation for component n. 
massf low_component ( : ) = 0 

Specifies what component to get the physical mass flow from to calculate 
the ideal thrust. 

throat_area( : ) = 0.0 

This is the throat area associated with component n. 

npr(:) = 0.0 

This is the set nozzle pressure ratio associated with component n. 

ntr ( : ) = 0.0 

This is the set nozzle temperature ratio associated with component n. 

allow_f low_through_f orces = .false. 

Pressure drag and skin friction forces are by default calculated only on 
boundary faces designated as solid surfaces ( viscous or inviscid ). To 
include the pressure and momentum flux forces due to nozzles or in- 
lets allow_f low_through_f orces should be set to .true.. The flow- 
through faces to be tracked should be listed in the component_count 
and component.input lists accordingly. 
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B.4.23 &time avg params 


This namelist controls the bookkeeping of time average and root mean square 
statistics for every point in the domain. Tracking these statistics enables vi- 
sualization of variables like p_tavg, u_trms, etc. See the visualization output 
variable namelists &volume_output_variables, &boundary_output_variables, 
and &sampling_output_variables for details. When these statistics are tracked, 
the hie [project_rootname] _TAVG.l maintains information across restarts. 
This statistics hie is similar to the [project_rootname] .flow restart hie in 
that is not intended for the user to interact with directly. 


&time_avg_params 

itime_avg = 0 

prior_time_avg = -1 

use_prior_time_avg = 1 
tavg_header_version = 1 

/ 


itime_avg = 0 

This controls collection of temporal statistics. 

‘ 0 J do not compute time averaging statistics. 

‘ 1 J compute time averaging statistics required for visualization. 
prior_time_avg = -1 

This option is deprecated, see use_prior_time_avg. 
use_prior_time_avg = 1 

This controls if a prior execution should contribute to the temporal 
statistics. 

‘ 1 ’ combines the prior statistics stored in [project_rootname] _TAVG.l 
with the statistics of this execution. If [project_rootname] _TAVG.l is 
not available in the current directory, only the statistics from this exe- 
cution will be calculated. 

discards prior statistics. The hie [projectxrootname] _TAVG.l will 
be ignored, if it exists. 

tavg_header_version = 1 

This option controls the variables for which statistics are collected. 

‘ 1 ’ for primitive variable averages and root mean squares. 

‘ 2 J for primitive variable averages, primitive variable root mean squares, 
and the averages of u’v J , u ’ w ’ ,v’w’ , mu_t , vort unag. 
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B.4.24 &:global 


This namelist controls the frequency of visualization output and the logging of 
command line options. It also serves to control some global options otherwise 
set by command- line input 

&global 

moving_grid 
grid_motion_only 
grid_motion_and_dci_only 
body_motion_only 
timing 

time_moving_grid 
boundary_animation_freq 
boundary_animation_freq_tavg 
volume_animation_f req 
slice_f req 

record_command_lines 
recompute_turb_dist 
turb_dist_update_f req 

/ 

moving_grid = .false. 

This governs whether the grid is moving or stationary 

grid_motion_only = .false. 

This turns off the flow solve during a simulation for which moving.grid = 
.true.. If the simulation involves overset grids, this command overrides 
dci_on_the_f ly and DCI hies are not output. 

grid_motion_and_dci_only = .false. 

This turns off the how solve during a simulation for which moving.grid 
= .true.. If the simulation involves overset grids, this command honors 
dci_on_the_f ly and DCI hies are output if dci_on_the_f ly = .true.. 

body_motion_only = .false. 

This turns oh both the how solve and the linear elasticity solve dur- 
ing a simulation for which moving_grid = .true, and grid_motion = 
’ deform J 

timing = .false. 

This triggers a timing of the execution of various sections of the how 
solver. 


= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= 0 
= 0 
= 0 
= 0 

= .false. 
= .false. 
= 1 
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time_moving_grid = .false. 


This triggers timing of the execution of various sections of the flow solver, 
with emphasis on operations associated with grid motion. The timing 
occurs over larger sections of the code than the timing option. For 
correct timing information, timing and time_moving_grid should not 
be used simultaneously. 

boundary_animation_freq = 0 

This is the visualization output frequency of the domain boundaries. 

Zero is no output, -1 is output at the end of run, and a positive integer 
is periodic output every boundary_animation_freq iterations. See the 
&boundary_output_variables namelist for more details. 

boundary_animation_freq_tavg = 0 

This is the visualization output frequency of time-averaged data on the 
domain boundaries. Zero is no output, - 1 is output at the end of run, and 
a positive integer is periodic output every boundary_animation_f req_tavg 
iterations. 

volume_animation_f req = 0 

This is the visualization output frequency of the domain volume. Zero 
is no output, - 1 is output at the end of run, and a positive integer is peri- 
odic output every volume_animation_f req iterations. See &volume_output_variables 
namelist for more details. 

slice_freq = 0 

This is the output frequency of boundary slices for visualization and to 
obtain loads. Zero is no output, -1 is output at the end of run, and 
a positive integer is periodic output every slice_freq iterations. See 
&slice_data namelist for more details. 

record_command_lines = .false. 

This creates a hie temp. commands that contains the command line argu- 
ments 

recompute_turb_dist = .false. 

This is a hag that allows for the distance function to be recomputed after 
grid deformation or when overset grids are moved. 

turb_dist_update_f req = 1 

This is the frequency with which the distance function is updated when 
recompute_turb_dist = .true.. 
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B.4.25 fcvolume output variables 

This namelist controls volume variable output. Output frequency is controlled 
by volume_animation_f req in the &global namelist. The resulting volume- 
data hies have the following naming convention for export_to= ) tecplot ’ 
output: 

[project_rootname] _part [P] _tec_volume_timestep [T] ( . dat | .pit) if freq > 0 
[project_rootname] _Part [P] _tec_volume( .dat | .pit) if freq < 0 

where P = 1,2,. . . ,nproc (number of processors) and T is the iteration number. 

The hie extension is .dat for ASCII Tecplot™ format and .pit for binary 
Tecplot™ format. Within the hies, a single zone is written, with the zone 
title “time 0.0000000E+00 processor 32” where the time value is the integer 
iteration number for steady-state cases, and the current (non-dimensional) 
time for time-dependent cases. 

A request to output an undefined variable will overruled, i.e., turbl will 
be forced to .false regardless of user input when there is no turbulence model 
in the simulation. 


&volume_output_variables 


export_to 

= 

' tecplot 

output _initial_st ate 

= 

.false . 

X 

= 

. true . 

y 

= 

. true . 

z 

= 

. true . 

primitive_variables 

= 

. true . 

rho 

- 

.false . 

u 

= 

.false . 

V 

= 

.false . 

w 

= 

.false . 

p 

= 

.false . 

entropy 

= 

.false . 

mach 

= 

.false . 

temperature 

= 

.false . 

iblank 

= 

.false . 

imesh 

= 

.false . 

vort_mag 

= 

.false . 

vort_x 

= 

.false . 

vort_y 

= 

.false . 

vort_z 

= 

.false . 

q_criterion 

= 

.false . 

div_vel 

= 

.false . 

turbulent _f luctuat i ons 

= 

.false . 

uuprime 

= 

.false . 

vvprime 

= 

.false . 
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wwprime 

uvprime 

uwprime 

vwprime 

cp 

dp_pinf 

volume 

residuals 

resl 

res2 

res3 

res4 

res5 

res_gcl 

primitive_tavg 

rho_tavg 

u_tavg 

v_tavg 

w_tavg 

P-tavg 

primitive_trms 

rho_trms 

u_trms 

v_trms 

w_trms 

p_trms 

lambdal 

lambda2 

lambda3 

lambda4 

lambda5 

lambda6 

lambda7 

htot 

ttot 

ptot 

etot 

processor_id 

turb_ke 

turb_diss 

mu_t 

turbl 

turb2 

turb3 

turb4 


= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
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turb5 

= 

.false 

turb6 

= 

.false 

turb7 

= 

.false 

turresl 

= 

.false 

turres2 

= 

.false 

turres3 

= 

.false 

turres4 

= 

.false 

turres5 

= 

.false 

turres6 

= 

.false 

turres7 

= 

.false 

slen 

= 

.false 

if lagslen 

= 

.false 

hrles_blend 

= 

.false 

r e construct ion_limiter_phil 

= 

.false 

re construct ion_limiter_phi 2 

= 

.false 

re construct ion_limiter_phi3 

= 

.false 

re construct ion_limiter_phi4 

= 

.false 

re construct ion_limiter_phi 5 

= 

.false 

tt 

= 

.false 

tv 

= 

.false 

sonic 

= 

.false 

mixture_mol_weight 

= 

.false 

mixture_density 

= 

.false 

ev 

= 

.false 

rho_i (1 :n_species) 

= 

.false 

mu 

= 

.false 

id_12g 

= 

.false 

divided_residuals 

= 

.false 


exportcto = ’ tecplot’ 
file format of volume export 

‘tecplot’ is Tecplot™ format (one file written for each processor) 

‘ cgns ’ is CGNS format, requires Fun3D to be configured with a CGNS 
library. This format already includes x, y, and z. Set these variables to 
.false, to avoid duplication. 

‘fvuns’ is FieldView C-binary (Fortran stream) format. This format 
already includes x, y, and z. Set these variables to .false, to avoid 
duplication. 

‘fv’ is depreciated. Slated for removal, use ’hums’ 

‘vtk’ is legacy VTK format This format already includes x, y, and z. 
Set these variables to .false, to avoid duplication. 

‘ csv’ is comma separated value format 
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‘ sol ’ is INRIA Metrix sol format 

'tec’ is a single image ASCII Tecplot M format 

‘raw-ascii’ is a single image ASCII space separated format 

‘ native J is the most efficient way to export the entire flow field to disk 
at every time step when the grid is over a billion elements, but requires 
specialized visualization tools to read. 

output_initial_state = .false. 

When .true., this causes requested volume data to be written for the 
initial state of the solution in the current run. 

x = .true. 

X-coordinate 

y = .true. 

Y -coordinate 

z = .true. 

Z-coordinate 

primitivervariables = .true. 

Output primitive variables: rho, u, v, w, and p 
rho = .false. 

Density 
u = .false. 

X-component of velocity 

v = .false. 

Y -component of velocity 

w = .false. 

Z-component of velocity 

p = .false. 

Pressure 

entropy = .false. 

Entropy 
mach = .false. 

Mach number 


182 



temperature = .false. 
Temperature 


iblank = .false. 

I-blanking variable (default becomes .true, for overset mesh cases) 

imesh = .false. 

For overset mesh systems, index of associated component grid where 0 
indicates background grid 

vortunag = .false. 

Vorticity magnitude 

vort_x = .false. 

X-component of vorticity 

vort_y = .false. 

Y -component of vorticity 

vort_z = .false. 

Z-component of vorticity 

q_criterion = .false. 

Q Criterion, the second invariant of VC 

div_vel = .false. 

Velocity divergence 

turbulent_f luctuations = .false. 

Activate all the following XYprime turbulent shear stresses normalized by 
v? re f \ the definition of these variables depends on the turbulence model, 
see http: //turbmodels. larc.nasa.gov/noteonrunning.html for details 

uuprime = .false. 

Turbulence fluctuation, u'u' 

vvprime = .false. 

Turbulence fluctuation, v'v' 

wwprime = .false. 

Turbulence fluctuation, w'w' 

uvprime = .false. 

Turbulence fluctuation, u'v' 
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uwprime = .false. 

Turbulence fluctuation, u'w' 
vwprime = .false. 

Turbulence fluctuation, v'w' 
cp = .false. 

Pressure coefficient 
dp_pinf = .false. 

Normalized delta pressure (p — Poo)/Poo 

volume = .false. 

Dual-cell volume size 
residuals = .false. 

Activate all resN variables 
resl = .false. 

Residual of equation 1, density 
res2 = .false. 

Residual of equation 2, ^-momentum 
res3 = .false. 

Residual of equation 3, ^/-momentum 
res4 = .false. 

Residual of equation 4, ^-momentum 
res5 = .false. 

Residual of equation 5, energy 

res_gcl = .false. 

For moving meshes, residual of grid conservation law 

primitivevtavg = .false. 

Output time-averaged primitives (requires &time_avg_params namelist): 
rho.tavg, u_tavg, v_tavg, w_tavg, and p_tavg 

rho.tavg = .false. 

Time- averaged density 

u_tavg = .false. 

Time-averaged x- component of velocity 
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v_tavg = .false. 

Time-averaged ^/-component of velocity 
w_tavg = .false. 

Time-averaged ^-component of velocity 

p_tavg = .false. 

Time- averaged pressure 
primitive_trms = .false. 

Output root mean squared primitives (requires &time_avg_params namelist): 
rho.trms, u_trms, v_trms, w_trms, and p_trms 

rho_trms = .false. 

RMS-average of density 

u_trms = .false. 

RMS-average of x- component of velocity 

v_trms = .false. 

RMS-average of ^/-component of velocity 

w_trms = .false. 

RMS-average of ^-component of velocity 

pjtrms = .false. 

RMS-average of pressure 

lambdal = .false. 

Adjoint Lagrange multiplier for equation 1 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda2 = .false. 

Adjoint Lagrange multiplier for equation 2 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda3 = .false. 

Adjoint Lagrange multiplier for equation 3 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda4 = .false. 

Adjoint Lagrange multiplier for equation 4 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 
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Iambda5 = .false. 

Adjoint Lagrange multiplier for equation 5 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda6 = .false. 

Adjoint Lagrange multiplier for equation 6 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda7 = .false. 

Adjoint Lagrange multiplier for equation 7 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

htot = .false. 

Total enthalpy per unit volume 
ttot = .false. 

Total temperature 
ptot = .false. 

Total pressure 
etot = .false. 

Total energy per unit volume 
processorvid = .false. 

Processor on which a node resides 
turb_ke = .false. 

Turbulence kinetic energy 
turb_diss = .false. 

Turbulence dissipation rate 
mu_t = .false. 

Turbulent eddy viscosity 
turbl = .false. 

Turbulence variable 1 (model dependent) 

turb2 = .false. 

Turbulence variable 2 (model dependent) 

turb3 = .false. 

Turbulence variable 3 (model dependent) 
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turb4 = .false. 

Turbulence variable 4 (model dependent) 

turb5 = .false. 

Turbulence variable 5 (model dependent) 

turb6 = .false. 

Turbulence variable 6 (model dependent) 

turb7 = .false. 

Turbulence variable 7 (model dependent) 
turresl = .false. 

Residual of 1st turbulence equation 
turres2 = .false. 

Residual of 2nd turbulence equation 
turres3 = .false. 

Residual of 3rd turbulence equation 
turres4 = .false. 

Residual of 4th turbulence equation 
turres5 = .false. 

Residual of 5th turbulence equation 
turres6 = .false. 

Residual of 6th turbulence equation 
turres7 = .false. 

Residual of 7th turbulence equation 
slen = .false. 

Length to the nearest solid wall boundary 
iflagslen = .false. 

Turbulence model distance function closest boundary entity, (a negative 
sign indicates the node has been prescribed as laminar) 

hrles_blend = .false. 

HRLES blending function 

reconstruction_liraiter_phil = .false. 

0 for the node-based reconstruction limiters (equation 1) 
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reconstruction_liraiter_phi2 = .false. 

0 for the node-based reconstruction limiters (equation 2) 
reconstruction_liraiter_phi3 = .false. 

0 for the node-based reconstruction limiters (equation 3) 
reconstruction_limiter_phi4 = .false. 

0 for the node-based reconstruction limiters (equation 4) 
reconstruction_limiter_phi5 = .false. 

0 for the node-based reconstruction limiters (equation 5) 
tt = .false. 

Translational temperature only for eqnvtype = ' generic ' 
tv = .false. 

Vibrational temperature only for eqn.type = ' generic ' 
sonic = .false. 

Frozen speed of sound only for eqn_type = 'generic 5 
mixturennol_weight = .false. 

Mixture molecular weight only for eqn.type = 'generic 5 
mixture_density = .false. 

Mixture density only for eqn.type = 'generic' 
ev = .false. 

Vibrational energy only for eqnvtype = 'generic' 
rho_i (1 : n.species) = .false. 

Species concentration only for eqn.type = 'generic' 
mu = .false. 

Total viscosity 
id_12g = .false. 

Local-to-global node map 
divided_residuals = .false. 

adds a _vol suffix to the residual output variable names and divide by 
volume 
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B.4.26 ^boundary output variables 

This namelist controls the boundary variable output. Output frequency is 
controlled by boundary _animation_freq in the &global namelist. By default, 
the output of solution data for all solid surfaces in 3D and on one ^/-constant 
symmetry plane in 2D is included unless boundarydList is specified. 

Each time boundary data output is triggered, all output boundaries are 
written to one hie with the following naming convention: 

[project_rootname] _tec_boundary_timestep [T] ( . dat | .pit) if N > 0 
[project_rootname] _tec_boundary( .dat | .pit) if N < 0 

where T is the iteration number. The hie extension is .dat for ASCII Tec- 
plot lM format and .pit for binary Tecplot M format. Within the hies, each 
boundary is written as a separate zone. The zones are identified with the title 
“time 0.0000000E+00 boundary 5” where the time value is the integer iter- 
ation number for steady-state cases, and the current (non-dimensional) time 
for time-dependent cases. 

By default, output is in the inertial reference frame. For moving body 
problems, the &observer_motion namelist can be used to change the visual- 
ization reference system to a body reference system or a reference system with 
arbitrary motion. 

A request to output an undehned variable will overruled, i.e., turbl will 
be forced to .false regardless of user input when there is no turbulence model 
in the simulation. 

&boundary_output_variables 


number _of_boundaries 

= 

0 

boundary_list 

= 

1 1 

output_initial_state 

= 

. false 

X 

= 

. true . 

y 

= 

. true . 

z 

= 

. true . 

primitive_ variables 

= 

. true . 

rho 

= 

. false 

u 

= 

. false 

V 

= 

. false 

w 

= 

. false 

P 

= 

. false 

entropy 

= 

. false 

mach 

= 

. false 

temperature 

= 

. false 

iblank 

= 

. false 

imesh 

= 

. false 

vort_mag 

= 

. false 

vort_x 

= 

. false 
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vort_y 

= 

. false 

vort_z 

= 

. false 

q_criterion 

= 

. false 

div_vel 

= 

. false 

turbulent _f luctuat i ons 

= 

. false 

uuprime 

= 

. false 

vvprime 

= 

. false 

wwprime 

= 

. false 

uvprime 

= 

. false 

uwprime 

= 

. false 

vwprime 

= 

. false 

cp 

= 

. false 

dp_pinf 

= 

. false 

volume 

= 

. false 

residuals 

= 

. false 

resl 

= 

. false 

res2 

= 

. false 

res3 

= 

. false 

res4 

= 

. false 

res5 

= 

. false 

res_gcl 

= 

. false 

primitive_tavg 

= 

. false 

rho_tavg 

= 

. false 

u_tavg 

= 

. false 

v_tavg 

= 

. false 

w_tavg 

= 

. false 

P-tavg 

= 

. false 

primitive_trms 

= 

. false 

rho_trms 

= 

. false 

u_trms 

= 

. false 

v_trms 

= 

. false 

w_trms 

= 

. false 

p_trms 

= 

. false 

lambda 1 

= 

. false 

lambda2 

= 

. false 

lambda3 

= 

. false 

lambda4 

= 

. false 

lambda5 

= 

. false 

lambda6 

= 

. false 

lambda7 

= 

. false 

htot 

= 

. false 

ttot 

= 

. false 

ptot 

= 

. false 

etot 

= 

. false 

processor_id 

= 

. false 
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turb_ke 

= 

. false 

turb_diss 

= 

. false 

mu_t 

= 

. false 

turbl 

= 

. false 

turb2 

= 

. false 

turb3 

= 

. false 

turb4 

= 

. false 

turb5 

= 

. false 

turb6 

= 

. false 

turb7 

= 

. false 

turresl 

= 

. false 

turres2 

= 

. false 

turres3 

= 

. false 

turres4 

= 

. false 

turres5 

= 

. false 

turres6 

= 

. false 

turres7 

= 

. false 

de_turbl 

= 

. false 

slen 

= 

. false 

tt 

= 

. false 

tv 

= 

. false 

sonic 

= 

. false 

mixture_mol_weight 

= 

. false 

mixture_density 

= 

. false 

ev 

= 

. false 

rho_i(l :n_species) 

= 

. false 

mu 

= 

. false 

id_12g 

= 

. false 

yplus 

= 

. false 

recovery_temperature 

= 

. false 

turb_mach 

= 

. false 

turbindex 

= 

. false 

average_velocity 

= 

. false 

uavg 

= 

. false 

vavg 

= 

. false 

wavg 

= 

. false 

surf ace_normals 

= 

. false 

cf _x 

= 

. false 

0 

l-h 

1 

= 

. false 

0 

l-h 

1 

N 

= 

. false 

skinfr 

= 

. false 

cq 

= 

. false 

shear_x 

= 

. false 

shear_y 

= 

. false 

shear_z 

= 

. false 
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heating 

= 

. false 

mdot 

= 

. false 

utau_wf 

= 

. false 

phi_wf 

= 

. false 

mu_t_wf 

= 

. false 

k_wallfunction_bc 

= 

. false 

omega_wallfunction_bc 

= 

. false 

blayer 

= 

. false 

tt_edge 

= 

. false 

tv_edge 

= 

. false 

rho_edge 

= 

. false 

p_edge 

= 

. false 

h_edge 

= 

. false 

u_edge 

= 

. false 

v_edge 

= 

. false 

w_edge 

= 

. false 

mach_edge 

= 

. false 

mu_edge 

= 

. false 

delta 

= 

. false 

deltastar 

= 

. false 

theta 

= 

. false 

re_ue 

= 

. false 

CH 

= 

. false 

stand_of f 

= 

. false 

number.of .boundaries 

_ 

0 


Number of boundary patches given in boundary.list (if -1 is given, this 
number is computed from boundary.list) 

boundary.list = ’ ’ 

List of boundary patch numbers. Commas and dashes can be used to 
specify ranges, i.e., ’1,2, 5-7 ’ . If nothing is specified, then all but flow- 
through boundaries are output for 3D or a single symmetry plane in 
2D. 

output_initial_state = .false. 

When .true., this causes requested boundary data to be written for the 
initial state of the solution in the current run. 

x = .true. 

X-coordinate 

y = .true. 

Y -coordinate 
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z = .true. 

Z-coordinate 

primitive.variables = .true. 

Output primitive variables: rho, u. v, w, and p 
rho = .false. 

Density 
u = .false. 

X-cornponent of velocity 
v = .false. 

Y -component of velocity 

w = .false. 

Z- component of velocity 

p = .false. 

Pressure 

entropy = .false. 

Entropy 
mach = .false. 

Mach number 
temperature = .false. 

Temperature 
iblank = .false. 

1-blanking variable (default becomes .true, for overset mesh cases) 

imesh = .false. 

For overset mesh systems, index of associated component grid where 0 
indicates background grid 

vortunag = .false. 

Vorticity magnitude 

vort_x = .false. 

X-component of vorticity 

vort_y = .false. 

Y -component of vorticity 
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vort_z 


.false. 


Z-component of vorticity 
q.criterion = .false. 

Q Criterion, the second invariant of VC 
div_vel = .false. 

Velocity divergence 

turbulent_f luctuations = .false. 

Activate all the following XYprime turbulent shear stresses normalized by 
the definition of these variables depends on the turbulence model, 
see http: //turbmodels. larc.nasa.gov/noteonrunning.html for details 

uuprime = .false. 

Turbulence fluctuation, u'u' 

vvprime = .false. 

Turbulence fluctuation, v'v' 

wwprime = .false. 

Turbulence fluctuation, w'w' 

uvprime = .false. 

Turbulence fluctuation, u'v' 

uwprime = .false. 

Turbulence fluctuation, u'w' 

vwprime = .false. 

Turbulence fluctuation, v'w' 

cp = .false. 

Pressure coefficient 

dp_pinf = .false. 

Normalized delta pressure (p — Poo)/Poo 

volume = .false. 

Dual-cell volume size 
residuals = .false. 

Activate all resN variables. 
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resl = .false. 

Residual of equation 1, density 
res2 = .false. 

Residual of equation 2, x-niornentum 
res3 = .false. 

Residual of equation 3, ^/-momentum 
res4 = .false. 

Residual of equation 4, ^-momentum 
res5 = .false. 

Residual of equation 5, energy 

res_gcl = .false. 

For moving meshes, residual of grid conservation law 

primitive_tavg = .false. 

Output time-averaged primitives (requires &tirae_avg_params namelist): 
rhovtavg, uvtavg, vvtavg, wvtavg, and pvtavg 

rhovtavg = .false. 

Time- averaged density 

u_tavg = .false. 

Time-averaged ^-component of velocity 
v_tavg = .false. 

Time-averaged ^/-component of velocity 

wvtavg = .false. 

Time-averaged ^-component of velocity 

p_tavg = .false. 

Time- averaged pressure 
primitivejtrms = .false. 

Output root mean squared primitives (requires &time_avg_params namelist): 
rho.trms, u_trms, v_trms, w_trms, and p_trms 

rho_trms = .false. 

RMS-average of density 
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u_trms = .false. 

RMS-average of x- component of velocity 

v_trms = .false. 

RMS-average of ^/-component of velocity 

w_trms = .false. 

RMS-average of ^-component of velocity 

p_trms = .false. 

RMS-average of pressure 

lambdal = .false. 

Adjoint Lagrange multiplier for equation 1 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda2 = .false. 

Adjoint Lagrange multiplier for equation 2 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda3 = .false. 

Adjoint Lagrange multiplier for equation 3 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda4 = .false. 

Adjoint Lagrange multiplier for equation 4 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda5 = .false. 

Adjoint Lagrange multiplier for equation 5 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda6 = .false. 

Adjoint Lagrange multiplier for equation 6 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda7 = .false. 

Adjoint Lagrange multiplier for equation 7 (when running the 
the primitive variables are turned off, and this is turned on) 

htot = .false. 

Total enthalpy per unit volume 
ttot = .false. 

Total temperature 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 
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ptot = .false. 

Total pressure 
etot = .false. 

Total energy per unit volume 
processor.id = .false. 

Processor on which a node resides 
turb_ke = .false. 

Turbulence kinetic energy 
turb_diss = .false. 

Turbulence dissipation rate 
mu_t = .false. 

Turbulent eddy viscosity 
turbl = .false. 

Turbulence variable 1 (model dependent) 

turb2 = .false. 

Turbulence variable 2 (model dependent) 

turb3 = .false. 

Turbulence variable 3 (model dependent) 

turb4 = .false. 

Turbulence variable 4 (model dependent) 

turb5 = .false. 

Turbulence variable 5 (model dependent) 

turb6 = .false. 

Turbulence variable 6 (model dependent) 

turb7 = .false. 

Turbulence variable 7 (model dependent) 
turresl = .false. 

Residual of 1st turbulence equation 
turres2 = .false. 

Residual of 2nd turbulence equation 
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turres3 = .false. 

Residual of 3rd turbulence equation 
turres4 = .false. 

Residual of 4th turbulence equation 
turres5 = .false. 

Residual of 5th turbulence equation 
turres6 = .false. 

Residual of 6th turbulence equation 
turres7 = .false. 

Residual of 7th turbulence equation 
de_turbl = .false. 

Discretization error of 1st turbulence equation 

slen = .false. 

Length to the nearest solid wall boundary 
tt = .false. 

Translational temperature, only for eqn.type = ’generic’ 
tv = .false. 

Vibrational temperature, only for eqn.type = ’generic’ 
sonic = .false. 

Frozen speed of sound, only for eqn.type = ’generic’ 
mixture_mol_weight = .false. 

Mixture molecular weight, only for eqn.type = ’generic’ 
mixture_density = .false. 

Mixture density, only for eqn_type = ’generic’ 
ev = .false. 

Vibrational energy, only for eqn.type = ’generic’ 
rho_i (1 : n.species) = .false. 

Species concentration, only for eqn_type = ’generic’ 
mu = .false. 

Total viscosity 
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id_12g = .false. 

Local-to-global node map 
yplus = .false. 

Dimensionless wall distance, y + 
recovery.temperature = .false. 

Recovery temperature (for eqn_type = ’ generic', a Prandtl number 
of 0.72 is assumed) 

turbunach = .false. 

Turbulent Mach number 

turbindex = .false. 

Turbulent index 

average_velocity = .false. 

Turns on uavg, vavg, wavg 

uavg = .false. 

X-component of average velocity near a wall (used to plot surface stream- 
lines) 

vavg = .false. 

Y -component of average velocity near a wall (used to plot surface stream- 
lines) 

wavg = .false. 

Z- component of average velocity near a wall (used to plot surface stream- 
lines) 

surf ace_normals = .false. 

Turns on surface normals: xnormal, ynormal, znormal; direction of the 
normal points into the computational domain. Note that individual nor- 
mal components are not selectable. 

cf_x = .false. 

X-component of skin friction 

cf_y = .false. 

Y -component of skin friction 

cf_z = .false. 

Z- component of skin friction 


199 



skinfr = .false. 

Skin friction magnitude with sign determined by the inner product of 
the skin friction vector and the freestream velocity vector 

cq = .false. 

Temperature gradient normal to the wall, with “dimensions” of nondi- 
mensional temperature per unit grid length for eqn.type = ' compressible ’ . 
Heating rate non-dimensionalized by pooV^ for eqn.type = ‘ generic ’ . 

shear_x = .false. 

X-component of shear on the boundary, in MKS units 
shear_y = .false. 

Y -component of shear on the boundary, in MKS units 
shear_z = .false. 

Z-component of shear on the boundary, in MKS units 

heating = .false. 

Heating on the boundary in Watts per centimeter squared (for eqn.type 
= ‘ compressible ’ , make sure the grid is in meters) 

mdot = .false. 

Dimensionless blowing rate non-dimensionalized by PooK» 
utau_wf = .false. 

Friction velocity calculated from a wall function model. 
phi_wf = .false. 

Pressure gradient term from a wall function model. 
mu_t_wf = .false. 

Wall function turbulent eddy viscosity at the wall. 
k_wallfunction_bc = .false. 

Turbulent kinetic energy wall function boundary condition. 

omega_wallfunction_bc = .false. 

Omega wall function boundary condition. 

blayer = .false. 

Output boundary layer edge quantities (only for eqn.type = ‘ generic ’ ). 
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tt_edge = .false. 


Boundary layer edge translational temperature. Only for eqn.type = 

’ generic ’ . 

tv_edge = .false. 

Boundary layer edge vibrational temperature. Only for eqn_type = 

’ generic ’ . 

rho.edge = .false. 

Boundary layer edge density. Only for eqn.type = ’generic’. 
p_edge = .false. 

Boundary layer edge pressure. Only for eqnrtype = ’generic’. 
h_edge = .false. 

Boundary layer edge enthalpy. Only for eqn_type = ’generic’. 
u_edge = .false. 

Boundary layer edge velocity, X-component. Only for eqn.type = ’ generic ’ 
v_edge = .false. 

Boundary layer edge velocity, Y-component. Only for eqn.type = ’ generic ’ 
w_edge = .false. 

Boundary layer edge velocity, Y-component. Only for eqnrtype = ’generic’ 
mach_edge = .false. 

Boundary layer edge Mach number. Only for eqn.type = ’generic’. 
mu_edge = .false. 

Boundary layer edge viscosity. Only for eqn_type = ’generic’. 
delta = .false. 

Boundary layer edge distance. Only for eqn_type = ’generic’. 
deltastar = .false. 

Boundary layer displacement thickness. Only for eqnrtype = ’generic’. 
theta = .false. 

Boundary layer momentum thickness. Only for eqn.type = ’ generic ’ . 
re_ue = .false. 

Reynolds number based on boundary layer edge velocity. Only for eqn.type 
= ’generic’. 
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CH = .false. 

Film coefficient. Only for eqn_type = ’ generic 1 . 
stancLoff = .false. 

Shock stand-off distance. Only for eqnrtype = ’generic’. 
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B.4.27 &:sampling output variables 

This namelist controls output of variables from user defined regions of the 
computational domain. To use sampling, the &sampling_parameters namelist 
must be used to define the sampling geometries and the sampling_f requency ( : 

) set for each geometry. 

The resulting sampling data hies will have the following naming convention: 

[project_rootname] _tec_sampling_geom [G] _timestep [T] ( . dat | .pit) if N > 0 
[project_rootname] _tec_sampling_geom[G] ( .dat | .pit) if N < 0 

where G = 1,2,. . . ,number_of .geometries, and T is the iteration number. The 
hie extension is .dat for ASCII Tecplot™ format and .pit for binary Tecplot™ 
format. A global image of the sampling surface is output with the zone title 
“time 0.0000000E+00 geom 3” where the time value is the integer iteration 
number for steady-state cases, and the current (nondimensional) time for time- 
dependent cases. 

A request to output an undefined variable will overruled, i.e., turbl will 
be forced to .false regardless of user input when there is no turbulence model 
in the simulation. 


&sampling_output_variables 


X 

= 

. true . 

y 

= 

. true . 

z 

= 

. true . 

primitive_ variables 

= 

. true . 

rho 

= 

.false 

rho_i ( : ) 

= 

.false 

u 

= 

.false 

V 

= 

.false 

w 

= 

.false 

p 

= 

.false 

entropy 

= 

.false 

mach 

= 

.false 

temperature 

= 

.false 

tt 

= 

.false 

tv 

= 

.false 

iblank 

= 

.false 

imesh 

= 

.false 

vort_mag 

= 

.false 

vort_x 

= 

.false 

vort_y 

= 

.false 

vort_z 

= 

.false 

q_criterion 

= 

.false 

div_vel 

= 

.false 

turbulent _f luctuat i ons 

= 

.false 
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uuprime 

vvprime 

wwprime 

uvprime 

uwprime 

vwprime 

cp 

dp_pinf 

volume 

residuals 

resl 

res2 

res3 

res4 

res5 

res_gcl 

rho_tavg 

primitive_tavg 

u_tavg 

v_tavg 

w_tavg 

P-tavg 

mu_t_tavg 

vort_mag_tavg 

vort_x_tavg 

vort_y_tavg 

vort_z_tavg 

primitive_trms 

rho_trms 

u_trms 

v_trms 

w_trms 

p_trms 

lambdal 

lambda2 

lambda3 

lambda4 

lambda5 

lambda6 

lambda7 

htot 

ttot 

ptot 

etot 

processor_id 


= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
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turb_ke 

= 

.false 

turb_diss 

= 

.false 

mu_t_wf 

= 

.false 

mu_t 

= 

.false 

turbl 

= 

.false 

turb2 

= 

.false 

turb3 

= 

.false 

turb4 

= 

.false 

turb5 

= 

.false 

turb6 

= 

.false 

turb7 

= 

.false 

turresl 

= 

.false 

turres2 

= 

.false 

turres3 

= 

.false 

turres4 

= 

.false 

turres5 

= 

.false 

turres6 

= 

.false 

turres7 

= 

.false 

slen 

= 

.false 

if lagslen 

= 

.false 

hrles_blend 

= 

.false 

vort_x_rms 

= 

.false 

vort_y_rms 

= 

.false 

vort_z_rms 

= 

.false 

vort_mag_rms 

= 

.false 

yplus 

= 

.false 

cmu_star 

= 

.false 

mu_t_ratio 

= 

.false 

iib 

= 

.false 

iiib 

= 

.false 

uplus 

= 

.false 

kplus 

= 

.false 

wplus 

= 

.false 

yplusretau 

= 

.false 

tllplus 

= 

.false 

tl2plus 

= 

.false 

tl3plus 

= 

.false 

t22plus 

= 

.false 

t23plus 

= 

.false 

t33plus 

= 

.false 

bird_breakdown 

= 

.false 

vgradrho 

= 

.false 

f _rl 

= 

.false 

xi_k 

= 

.false 

r e construct ion_limiter_phil 

= 

.false 
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reconstruction_limiter_phi2 = .false. 
reconstruction_limiter_phi3 = .false. 
reconstruction_limiter_phi4 = .false. 
reconstruction_limiter_phi5 = .false. 

x = .true. 

X-coordinate 
y = .true. 

Y -coordinate 
z = .true. 

Z-coordinate 

primitive.variables = .true. 

Output primitive variables: rho, u, v, w, and p 

rho = .false. 

Density 

rho_i(:) = .false. 

Species densities 
u = .false. 

X-component of velocity 

v = .false. 

Y -component of velocity 

w = .false. 

Z- comp orient of velocity 
p = .false. 

Pressure 

entropy = .false. 

Entropy 
mach = .false. 

Mach number 
temperature = .false. 

Temperature 
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tt 


.false. 


Translational-rotational temperature in the generic gas path 

tv = .false. 

Vibrational-electronic temperature in the generic gas path 

iblank = .false. 

I-blanking variable (default becomes .true, for overset mesh cases) 

imesh = .false. 

For overset mesh systems, index of associated component grid where 0 
indicates background grid 

vortunag = .false. 

Vorticity magnitude 

vort_x = .false. 

X-cornponent of vorticity 

vort_y = .false. 

Y -component of vorticity 

vort_z = .false. 

Z-component of vorticity 

q_criterion = .false. 

Q Criterion, the second invariant of W 

div_vel = .false. 

Velocity divergence 

turbulent_f luctuations = .false. 

Activate all the following XYprirae turbulent shear stresses normalized by 
the definition of these variables depends on the turbulence model, 
see http: //turbmodels. larc.nasa.gov/noteonrunning.html for details 

uuprime = .false. 

Turbulence fluctuation, u'v! 
vvprime = .false. 

Turbulence fluctuation, v'v' 
wwprime = .false. 

Turbulence fluctuation, w'w' 
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uvprime = .false. 

Turbulence fluctuation, u'v' 
uwprime = .false. 

Turbulence fluctuation, u'w' 
vwprime = .false. 

Turbulence fluctuation, v'w' 
cp = .false. 

Pressure coefficient 
dp_pinf = .false. 

Normalized delta pressure ( p — Poo)/Poo 

volume = .false. 

Dual-cell volume size 
residuals = .false. 

Activate all resN variables 
resl = .false. 

Residual of equation 1, density 
res2 = .false. 

Residual of equation 2, x-momentum 
res3 = .false. 

Residual of equation 3, y-momentum 
res4 = .false. 

Residual of equation 4, z-momentum 
res5 = .false. 

Residual of equation 5, energy 
res_gcl = .false. 

For moving meshes, residual of grid conservation law 
rho.tavg = .false. 

Time- averaged density 

primitive.tavg = .false. 

Output time-averaged primitives (requires &time_avg_params namelist): 
rho.tavg, u_tavg, v_tavg, w_tavg, and p_tavg 
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u_tavg = .false. 

Time-averaged x-component of velocity 
v_tavg = .false. 

Time-averaged y-component of velocity 

w_tavg = .false. 

Time-averaged z-component of velocity 
p_tavg = .false. 

Time- averaged pressure 
mu_t_tavg = .false. 

Time-averaged turbulent eddy viscosity 
vort unag.tavg = .false. 

Time-averaged vorticity magnitude 
vort_x_tavg = .false. 

Time-averaged x-component vorticity 
vort_y_tavg = .false. 

Time-averaged y-component vorticity 
vort_z_tavg = .false. 

Time-averaged z-component vorticity 
primitive_trms = .false. 

Output root mean squared primitives (requires &time_avg_params namelist): 
rho.trms, u_trms, v_trms, w_trms, and p_trms 

rho_trms = .false. 

RMS-average of density 

u_trms = .false. 

RMS-average of x-component of velocity 

v_trms = .false. 

RMS-average of y-component of velocity 

w_trms = .false. 

RMS-average of z-component of velocity 
p_trms = .false. 

RMS-average of pressure 
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lambdal = .false. 

Adjoint Lagrange multiplier for equation 1 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda2 = .false. 

Adjoint Lagrange multiplier for equation 2 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda3 = .false. 

Adjoint Lagrange multiplier for equation 3 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda4 = .false. 

Adjoint Lagrange multiplier for equation 4 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda5 = .false. 

Adjoint Lagrange multiplier for equation 5 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda6 = .false. 

Adjoint Lagrange multiplier for equation 6 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda7 = .false. 

Adjoint Lagrange multiplier for equation 7 (when running the 
the primitive variables are turned off, and this is turned on) 

htot = .false. 

Total enthalpy per unit volume 
ttot = .false. 

Total temperature 
ptot = .false. 

Total pressure 
etot = .false. 

Total energy per unit volume 
processor.id = .false. 

Processor on which a node resides 
turb_ke = .false. 

Turbulence kinetic energy 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 


adjoint, 
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turb_diss = .false. 

Turbulence dissipation rate 
mu_t_wf = .false. 

Turbulent eddy viscosity at the wall from a wall function model. 
mu_t = .false. 

Turbulent eddy viscosity 

turbl = .false. 

Turbulence variable 1 (model dependent) 
turb2 = .false. 

Turbulence variable 2 (model dependent) 

turb3 = .false. 

Turbulence variable 3 (model dependent) 

turb4 = .false. 

Turbulence variable 4 (model dependent) 

turb5 = .false. 

Turbulence variable 5 (model dependent) 

turb6 = .false. 

Turbulence variable 6 (model dependent) 

turb7 = .false. 

Turbulence variable 7 (model dependent) 
turresl = .false. 

Residual of 1st turbulence equation 
turres2 = .false. 

Residual of 2nd turbulence equation 
turres3 = .false. 

Residual of 3rd turbulence equation 
turres4 = .false. 

Residual of 4th turbulence equation 
turres5 = .false. 

Residual of 5th turbulence equation 
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turres6 = .false. 

Residual of 6th turbulence equation 
turres7 = .false. 

Residual of 7th turbulence equation 
slen = .false. 

Length to the nearest solid wall boundary 
iflagslen = .false. 

Turbulence model distance function closest boundary entity, (a negative 
sign indicates the node has been prescribed as laminar) 

hrles_blend = .false. 

HRLES blending function 

vort_x_rms = .false. 

RMS-average of x- component of vortic-ity 

vort_y_rras = .false. 

RMS-average of ^/-component of vorticity 

vort_z_rms = .false. 

RMS-average of z-component of vorticity 

vort_mag_rms = .false. 

RMS-average of vorticity magnitude 

yplus = .false. 

Dimensionless wall distance, y + 

cmu_star = .false. 

k — e model turbulent length scale parameter 

mu_t_ratio = .false. 

Ratio of turbulent eddy viscosity to laminar (bulk) viscosity 
iib = .false. 

— trace(R,;j * B ^)/ 2 
iiib = .false. 
trace (Ry * B ^ * Bij )/ 3 
uplus = .false. 

Dimensionless velocity, u + 
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kplus = .false. 


_k_ 

«? 

wplus = .false. 

UW_ 

ul 

yplusretau = .false. 


re T 


tllplus = 

.false. 

Til 


tl2plus = 

.false. 

Tl2 


tl3plus = 

.false. 

T 13 


t22plus = 

.false. 

r + 

'22 


t23plus = 

.false. 

r + 

'23 


t33plus = 

.false. 

r + 

'33 


bird_breakdown = .false. 

Bird continuum breakdown parameter 
vgradrho = .false. 

[u, v, w] ■ Vp 
f_rl = .false. 

Curvature correction model function 
xi_k = .false. 

Cross-diffusion term for Wilcox k-uj 1998 
reconstruction_liraiter_phil = .false. 

(j) for the node-based reconstruction limiters 
reconstruction_liraiter_phi2 = .false. 

0 for the node-based reconstruction limiters 


(equation 1) 
(equation 2) 
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reconstruction_liraiter_phi3 = .false. 

0 for the node-based reconstruction limiters (equation 3) 
reconstruction_liraiter_phi4 = .false. 

0 for the node-based reconstruction limiters (equation 4) 
reconstruction_limiter_phi5 = .false. 

0 for the node-based reconstruction limiters (equation 5) 
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B.4.28 &:sampling parameters 


This namelist specifies the types and frequency of sampling data to be ex- 
ported for visualization. The output variables themselves are specified in the 
&sampling_output_variables namelist. The last dimension of each array 
references the geometry index, which is one to number_of ^geometries. 

& s amp 1 i ng_p ar ame t e r s 


number _of _geometries 

= 

0 

sampling_f requency ( : ) 

= 

0 

label ( : ) 

= 

1 1 

type_of _geometry ( : ) 

= 

1 none ' 

crinkle 

= 

.false . 

nodal 

= 

.false . 

output _initial_st ate 

= 

.false . 

plot ( : ) 

= 

' tecplot 

patch_list_count ( : ) 

= 

0 

patch_list ( : ) 

= 

1 1 

type_of _data( : ) 

= 

' volume ' 

move_with_body ( : ) 

= 

i i 

boundary_list 

= 

i i 

def ault_boundary 

= 

. true . 

plane_center (1:3, : ) 

= 

0.0 

plane_normal (1:3, : ) 

= 

0.0 

box_lower_corner (1 :3, : ) 

= 

0.0 

box_upper_corner (1 :3, : ) 

= 

0.0 

sphere_center (1:3, : ) 

= 

0.0 

sphere_radius ( : ) 

= 

0.0 

circle_center (1 :3, : ) 

= 

0.0 

circle_normal (1 : 3 , : ) 

= 

0.0 

circle_radius ( : ) 

= 

0.0 

cylinder_f acel (1 :3, : ) 

= 

0.0 

cylinder_f ace2(l :3, : ) 

= 

0.0 

cylinder_radius ( : ) 

= 

0.0 

cone_f acel (1 : 3 , : ) 

= 

0.0 

cone_f ace2(l : 3 , :) 

= 

0.0 

cone_radiusl ( : ) 

= 

0.0 

cone_radius2 ( : ) 

= 

0.0 

cornerld :3, : ) 

= 

0.0 

corner2(l :3, : ) 

= 

0.0 

corner3(l :3, : ) 

= 

0.0 

corner4(l :3, : ) 

= 

0.0 

number_of _points ( : ) 

= 

0 

points (1 : 3 , : , : ) 

= 

0.0 

pl_line(l :3, : ) 

= 

0.0 

p2_line(l :3, : ) 

= 

0.0 
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schlieren_aspect 

= 

1 1 

window_height ( : ) 

= 

0.0 

window_width( : ) 

= 

0.0 

window_center (1:3, : ) 

= 

0.0 

number_of _rows ( : ) 

= 

0 

number_of _columns ( : ) 

= 

0 

model_center (1:3, : ) 

= 

0.0 

plot_lines ( : ) 

= 

.false 

make_shadow 

= 

.false 

blanking_list_count ( : ) 

= 

0 

blanking_list ( : ) 

= 

1 1 

isosurf _variable ( : ) 

= 

'P' 

isosurf _value ( : ) 

= 

0.0 

isosurf _box( : ) 

= 

.false 

x_range_lower ( : ) 

= 

-1.0 

x_range_upper ( : ) 

= 

1.0 

y_range_lower ( : ) 

= 

-1.0 

y_range_upper ( : ) 

= 

1.0 

z_range_lower ( : ) 

= 

-1.0 

z_range_upper ( : ) 

= 

1.0 

isosurf _dist_threshold( : ) 

= 

0.0 

variable_list ( : ) 

= 

1 1 

snap_output_xyz 

= 

. true . 

dist_tolerance 

= 

1.0e-3 

fwh_f ormatted 

= 

.false 

append_history ( : ) 

= 

.false 

asynchronous_fwh 

= 

.false 

boundary _point (1 :3, : ) 

= 

0.0 

boundary ( : ) 

= 

0 

need_wall_data( : ) 

= 

.false 

ref erence_length 

= 

0.0 

number_of ^geometries = 

0 



This is the total number of sampling geometries. 

sampling.f requency ( : ) = 0 

This specifies the iteration interval at which sampling is performed. The 
special value of -1 means to only perform sampling at the end of a 
successful run. 

label ( : ) = » ; 

This customizes the filename of sampling output. When it is blank, the 
file will be [project_rootname] _tec_sampling_geomN. (dat , pit) where 
N is the sampling geometry number, .dat is ASCII format, and .pit is 
binary format. 
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type.of .geometry (: ) = ’none’ 

This is the type of sampling geometry, 

' streamsurf ace ’ is a stream surface, requires number_of .points and 
points. 

' boundary.points ’ for boundary point sampling, requires number.of .points 
and points, modified by snap_output_xyz and dist.tolerance. 

' volume.points ’ for point sampling in the domain, requires number.of .points 
and points. 

‘ schlieren’ is a schlicren image via an integral of the refractive index 
field, requires number.of .rows, number.of .columns, windowJieight, window.width, 
window.center, and schlieren.aspect. It is controlled by make.shadow 
and plot.lines. 

' isosurface ’ is an isosurface that requires isosurf .variable and isosurf .value. 
It is controlled by *_range_lower and *_range_upper. 

' box’ samples a the surface of a box. It requires box.lower.corner and 
box.upper .corner. 

' sphere ’ samples a spherical surface. It requires sphere.center and 
sphere_radius. 

'cylinder’ samples a cylindrical surface. It requires cylinder.f acel, 
cylinder.f ace2, and cylinder_radius. 

'cone’ samples a conic surface. It requires cone_facel, cone_face2, 
cone_radiusl, and cone_radius2. 

'plane’ samples a plane. It requires plane.center and plane_normal. 

'quad’ samples a quadrilateral. It requires cornerl, corner2, corner3, 
corner4, and window_normal. 

'circle’ samples a circle. It requires circle.center, circle .normal, 
and circle_radius. 

' line’ is line sampling, which requires pl.line and p2_line. 
crinkle = .false. 

This snaps the sampling surface to nearest grid faces instead of using 
linear interpolation. 

nodal = .false. 

This uses the nearest nodal values instead of interpolating, 
output.initial.state = .false. 

When .true., this causes requested sampling data to be written for the 
initial state of the solution in the current run. 
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plot ( : ) = 'tecplot' 

This is the format of sampling output, 

‘tecplot’ Tecplot™ format. 

‘ f wlT format for Ffowcs Williams-Hawkings analysis. 

‘ serial_history 5 custom low-overhead point sampling format where 
all locations listed once at the top and then just the requested values 
per samplingJrrequency. 

patch_list_count ( : ) = 0 

This is the number of patches in patch_list. 

patch_list ( : ) = ’ ’ 

A string list of patch face IDs to limit boundary survey to a subset of 
the boundary faces. Commas and dashes can be used to specify ranges, 
i.e., ’ 1 , 2 , 5 - 7 ’. 

type.of _data( : ) = ’ volume’ 

The source of data for extracting the requested sampling variables for 
each type_of ^geometry. 

‘ volume ' extract data from the computational volume. 

‘ boundary ’ extract data from a boundary. 

'integrated' extract data from the computational volume and inte- 
grate over defined geometry. 

move_with_body ( : ) = ’’ 

Move the sampling geometry with the body if body is in motion. Use 
the fixed inertial reference frame when blank. 

boundary.list = ’ ’ 

List of patches to include when sampling boundaries; Commas and 
dashes can be used to specify ranges, i.e., ’ 1 , 2 , 5-7 ’ . 

default -boundary = .true. 

Use FUN3D default solid- wall-only boundary patches when sampling 
boundary points, i.e., ignore symmetry, slip, and flow-through bound- 
aries. 

plane_center (1 : 3, : ) = 0.0 

This is a point on a requested sampling ’ plane ’ ; it fixes the location. 
plane_normal (1 : 3, : ) = 0.0 

This is a normal vector of sampling ’ plane ’ ; it fixes the orientation. 
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box_lower_corner (1 : 3, : ) = 0.0 

This is the coordinate of the lower corner of a ’ box ’ . 

box_upper_corner (1 : 3, : ) = 0.0 

This is the coordinate of the upper corner of a ’ box ’ . 

sphere.center (1 : 3 , : ) = 0.0 

This is the coordinate of ’ sphere ’ center; it fixes the location. 
sphere_radius ( : ) = 0.0 

This is the radius for ’ sphere ’ ; it fixes the size. 
circle_center (1 : 3 , : ) = 0.0 

This is the coordinate of center of a ’ circle ’ ; it fixes the location. 
circle_normal(l :3, : ) = 0.0 

This is the normal vector for a ’ circle ’ ; it fixes the orientation. 
circlexradius ( : ) = 0.0 

This is the radius for a ’ circle’ ; it fixes the size, 
cylinder.f acel (1 : 3, : ) = 0.0 

This is the coordinate for the center of the first face of a ’ cylinder’ . 
cylinder^ ace2(l : 3, : ) = 0.0 

This is the coordinate for center of the second face of a ’ cylinder’ . 

cylinderxradius ( : ) = 0.0 
This is the radius of a ’ cylinder’ . 

cone_f acel (1 : 3 , : ) = 0.0 

This is the coordinate for center of the first face of a ’ cylinder’ . 
cone_f ace2 (1 : 3 , : ) = 0.0 

This is the coordinate for center of the second face of a ’ cylinder’ . 
cone_radiusl ( : ) = 0.0 

This is the radius of the first face of a ’ cone ’ . 
cone_radius2 ( : ) = 0.0 

This is the radius of the second face of a ’ cone ’ . 
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cornerl (1 : 3, : ) = 0.0 

This is the coordinate of the first corner of a ’ quad ’ ; the corners proceed 
clockwise. 

corner2 (1 : 3, : ) = 0.0 

The coordinate of the second corner of a ’ quad ’ . 
corner3(l : 3, : ) = 0.0 

The coordinate of the third corner of a ’ quad ’ . 
corner4(l : 3, : ) = 0.0 

The coordinate of the fourth corner of a ’ quad ’ . 
number.of .points (: ) = 0 

This is the number of points to be sampled by ’ boundary.point ’ or 
’ volume.point ’ . 

points (1 : 3, : , : ) = 0.0 

These are the coordinates of boundary.point and volume.point sam- 
pling. The first index is the Cartesian direction, the second index is the 
geometry, and the last index is the point in this geometry. 

pl-line(l :3, :) =0.0 

This is the first end point of a line in line sampling. 
p2_line(l:3, :) = 0.0 

This is the second end point of a line in line sampling, 
schlieren.aspect = ’ ’ 

This is the Cartesian direction for ’schlieren’ view, 

‘ y ’ Schlicren viewing along y axis. 

‘z’ Schlicren viewing along z axis. 

‘ yl ’ Schlicren viewing along y axis. 

‘ zl ’ Schlieren viewing along z axis. 

‘ ’ Schlieren viewing along window_normal. 

window_height ( : ) = 0.0 

This is the window height for ’ schlieren ’ . 

window_width( : ) = 0.0 

This is the window width for ’ schlieren’ . 
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window.center (1 : 3 , : ) = 0.0 

This is the window center for ’ schlieren’ . 

number _of _rows (: ) = 0 

This is the vertical number of pixels in the ’ schlieren’ window. 
number_of .columns (: ) = 0 

This is the horizontal number of pixels in the ’ schlieren ’ window. 

model_center (1 : 3, : ) = 0.0 

This is the model center for ’ schlieren ’ . 

plot-lines (: ) = .false. 

This plots lines for ’ schlieren’ . 
make_shadow = .false. 

The boundary will cast a shadow in schlieren output. 
blanking_list_count ( : ) = 0 

This is the number of boundaries to search for ’ schlieren ’ boundary 
shadow. 

blanking_list (: ) = ’’ 

This is a list of boundaries to search for ’ schlieren’ shadow. Commas 
and dashes can be used to specify ranges, i.e., ’1,2, 5-7’ . 

isosurf .variable ( : ) = ’p’ 

This is the variable used to define the geometry of an ’ isosurface ’ and 
isocrinkle. 

‘p’ Pressure. 

‘ rho ’ Density. 

‘u’ X-component of velocity. 

‘ v ’ Y -component of velocity. 

‘ w ’ Z-component of velocity. 

'vort-X’ X-component of vorticity. 

'vort-y’ Y -component of vorticity. 

'vort-z’ Z-component of vorticity. 

'vortunag’ Total magnitude of vorticity vector. 

‘ vort_mag_avg’ Average total magnitude of vorticity vector. 

‘ vort_mag_rms ’ RMS total magnitude of vorticity vector. 
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' q_criterion’ Q-criterion. 

' raach ’ Mach number. 

'temperature’ Temperature. 

'p_tavg’ Time average pressure. 

'rho.tavg’ Time average density. 

'urtavg’ Time average ^-component of velocity. 

'v_tavg’ Time average ^/-component of velocity. 

'wrtavg’ Time average ^-component of velocity. 

' p_trms ’ RMS of pressure. 

'rho.trms’ RMS of density. 

' u_trms ’ RMS of the ^-component of velocity. 

' v_trms ’ RMS of the ^/-component of velocity. 

' wrtrms ’ RMS of the ^-component of velocity. 

'critical.d’ critical d 
' sla’ other option 
'sib’ other option 
' si ’ other option 
' s2 ’ other option 

' lambdal ’ Adjoint variable for the 1st governing equation. 

' lambda2 ’ Adjoint variable for the 2nd governing equation. 

' lambda3’ Adjoint variable for the 3rd governing equation. 

' lambda4’ Adjoint variable for the 4th governing equation. 

' lambda5 ’ Adjoint variable for the 5th governing equation. 

' lambda6 ’ Adjoint variable for the 6th governing equation. 

' lambda7’ Adjoint variable for the 7th governing equation. 

' processor_id’ The assigned processor ID. 

' bird_breakdown’ Bird breakdown factor. 
isosurf _value( : ) = 0.0 

This is the value of isosurf _variable( : ) to create the ’isosurface’ 
and isocrinkle geometry. 

isosurf _box( : ) = .false. 

This clips the sampling geometry to be inside a box sized by *_range_* 
within isosurf _dist_threshold. 
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.true. 


x_range_lower ( : ) = -1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = 
x_range_upper ( : ) = 1.0 
This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
y_range_lower ( : ) = -1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
y_range_upper ( : ) = 1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
z_range_lower ( : ) = -1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
z_range_upper ( : ) = 1.0 

This limits isosurface or isocrinkle when isosurf _box( : ) = .true. 
isosurf _dist_threshold( : ) = 0.0 

This trims portions of an isosurface or isocrinkle that have a dis- 
tance to the surface less then this threshold. It requires isosurf _box( : 
) = .true. 

variable_list ( : ) = ’’ 

These variables augment &sampling_output_variables for this sam- 
pling object. 

snap_output_xyz = .true. 

This snaps the requested points to the nearest surface. 

distrtolerance = 1.0e-3 

This is the tolerance used when snap_output_xyz is engaged. 
fwh_f ormatted = .false. 

Write Ffowcs Williams-Hawkings in Fortran unformatted format. The 
default is Fortran stream (C-binary). 

append_history ( : ) = .false. 

This option removes the step number from the filename and opens it 
with append. 

asynchronous_fwh = .false. 

This uses asynchronous I/O for permeable FWH output. 
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boundary.point (1 : 3, : ) = 0.0 

This defines the location on a boundary where the friction velocity is 
to be calculated for use in plotting data in wall units. Additional input 
that is required is boundary (ib) . 

boundary(:) = 0 

This defines the boundary on which boundary _po int (1 : 3 , ib) will be 
found. 

need_wall_data( : ) = .false. 

This option activates the calculation of the friction velocity at a point 
on a wall for plotting of data in wall units. Other required input would 
be boundary(ib) and boundary _po int ( : ,ib). A sample asking for a 
boundary layer profile in wall units on boundary number 2 at the point 
(4., 0.05,0.) could have the following form: 

&sampling_parameters 
number_of _geometries = 1 
type_of _geometry (1) = 'line' 

pl_line ( : , 1) =4.0,0.05,-10. 

p2_line ( : , 1) =4.0,0.05, 10. 

boundary (1) = 2 

boundary_point ( : , 1) = 4.0,0.05,0. 

need_wall_data(l) = T 

var iable_list ( 1 ) = ' uplus , yplus , kplus , wplus ' 
sampling_frequency (1) = -1 
/ 

ref erencedLength = 0.0 

This is the reference length for Re r used in &sampling_output_variables. 
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B.4.29 &slice data 


This namelist specifies boundary slices for visualization and to obtain loads. 
Output frequency is controlled by sliced: req in the &global namelist, where 
zero for no output, -1 for output at the end of run, and a positive integer for 
periodic output. 

This is a limited ability to take slices through boundary surfaces. For 
example, spanwise cuts along a wing may be extracted, and then the resulting 
pressure and skin friction data may be plotted at each station. Slices can 
only be extracted in Cartesian planes (e.g., constant y ). For moving-body 
cases, the slices may be taken at constant coordinate positions in the body-fixed 
coordinate system, in which case the slices will not generally be in Cartesian 
planes in inertial space. 

Each slice will be written as one or more zones (loops) in an ASCII for- 
matted Tecplot™ file with the naming convention: 

[pro j ect_rootname] _slice . dat 

The variables output to this file are: x, y, z, cp, cfx, cfy, and cfz at each 
output time step. These slicing output variables are not customizable by the 
user. 

Slicing occurs in the inertial frame, unless an alternate reference frame is 
specified. For stationary geometries, the inertial frame is the only option. For 
moving body cases, either the frame of one of the moving bodies or an observer 
frame may specified. 

When slicing boundary surfaces, a file called slice. info is output that 
echos much of the input data. When the slicing is successful, the file will also 
contain information about the number of points in the slice. 

Below, namelist variables are defined. See section B.4.29 for some impor- 
tant considerations when using this capability. 

&slice_data 


nslices 

= 

0 

replicate_all_bodies 

= 

.false . 

output _initial_st ate 

= 

.false . 

slice_x( : ) 

= 

.false . 

slice_y ( : ) 

= 

. true . 

slice_z( : ) 

= 

.false . 

slice_location( : ) 

= 

0.0 

si ice_ increment 

= 

0.0 

xx_box_max( : ) 

= 

huge (1 . 0) 

yy_box_max( : ) 

= 

huge (1 . 0) 

zz_box_max( : ) 

= 

huge (1 . 0) 

xx_box_min( : ) 

= 

-huge (1 . 0) 

yy_box_min( : ) 

= 

-huge (1 . 0) 
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zz_box_min( : ) 
slice_xmc ( : ) 
slice_ymc ( : ) 
slice_zmc ( : ) 
n_bndrys_to_slice ( : ) 
bndrys_to_slice( : , : ) 
slice_f rame ( : ) 
slice_group( : ) 
chord_dir ( : ) 
te_def ( : ) 
le_def ( : ) 
corner_angle ( : ) 
use_local_ chord 
tecplot_slice_output 
output _sectional_f or ces 
slice_initial_coords 
custom_transf orm(l , 1,1:4) 
custom_transf orm(l , 2,1:4) 
custom_transf orm(l ,3, 1 : 4) 
custom_transf orm(l ,4, 1 : 4) 
output_in_slice_coords( : ) 


-huge (1 . 0) 
huge (1 . 0) 
huge (1 . 0) 
huge (1 . 0) 

0 

0 
I I 

1 

1 

1 

30 

120.0 
. true . 

. true . 

. true . 
.false . 


1 . 

. 0 , 

0 . 

, 0 , 

0 . 

. 0 , 

0 . 

.0 

0 . 

. 0 , 

1 . 

, 0 , 

0 . 

. 0 , 

0 . 

.0 

0 . 

. 0 , 

0 . 

, 0 , 

1 . 

. 0 , 

0 . 

.0 

0 . 

. 0 , 

0 . 

, 0 , 

0 . 

. 0 , 

1 . 

.0 


.false . 


nslices = 0 

This is the number of slices to create. If negative, then data for only 
one slice station need be input, along with slice_increment, and all the 
data specified for the first station will be applied to subsequent stations, 
with the exception of the slice location, which will be set using the slice 
increment between stations. 

replicate_all_bodies = .false. 

This will set similar slice stations on multiple bodies with minimal input 
beyond that required for slicing the first body. This is particularly useful 
for rotorcraft applications where multiple blades are to be sliced. This 
variable duplicates the input slice info for all moving bodies, with the 
exception of the slice_frame and the bndrys_to_slice. 

output_initial_state = .false. 

When .true., this causes requested slice data to be written for the initial 
state of the solution in the current run. 

slice_x(:) = .false. 

This extracts the slice at x — slice.location in the specified reference 
frame. 


226 



slice_y(:) = .true. 

This extracts the slice at y — slicedLocation in the specified reference 
frame. 

slice_z(:) = .false. 

This extracts the slice at z — slice_location in the specihed reference 
frame. 

slice_location( : ) = 0.0 

This is the coordinate value at which slice is taken. 
slice_increment = 0.0 

When nslices is negative, this is the increment in slice coordinate be- 
tween consecutive slice stations. 

xx_box_max ( : ) = huge (1.0) 

This is the maximum ^-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

yyvbox unax ( : ) = huge (1.0) 

This is the maximum //-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

zz_box unax ( : ) = huge (1.0) 

This is the maximum ^-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

xx_boxunin( : ) = -huge (1.0) 

This is the minimum ^-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

yy_boxunin( : ) = -huge (1.0) 

This is the minimum //-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

zz_boxunin( : ) = -huge (1.0) 

This is the minimum ^-coordinate used to define a bounding box to 
constrain the slicing to filter unwanted intersections. 

slice_xmc(:) = huge (1.0) 

This is the ^-coordinate of the moment center, in the specihed reference 
frame, for aerodynamic moments acting on the slice. The default value 
will result in the moment center being taken as the computed quarter 
chord of the slice. 
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slice_ymc(:) = huge(l.O) 

This is the ^/-coordinate of the moment center, in the specified reference 
frame, for aerodynamic moments acting on the slice. The default value 
will result in the moment center being taken as the computed quarter 
chord of the slice. 

slice_zmc(:) = huge(l.O) 

This is the ^-coordinate of the moment center, in the specified reference 
frame, for aerodynamic moments acting on the slice. The default value 
will result in the moment center being taken as the computed quarter 
chord of the slice. 

n_bndrys_to_slice ( : ) = 0 

This is the number of candidate boundaries to search while computing 
slice-plane intersections. The index is the slice. By default, all solid 
boundaries will be searched. Specifying which boundaries are candidates 
for slicing may speed up the slicing process and can be used to filter out 
unwanted intersections or to slice non-solid boundaries. 

bndrys_to_sli.ee ( : , : ) = 0 

This is the list of n_bndrys_to_slice boundaries, when the variable 
n_bndrys_to_slice is greater than zero. The first index is the slice 
and the second index is the boundary. 

slice_frame( : ) = ’’ 

This is the name of the slice reference frame. Blank indicates the iner- 
tial frame. For moving geometries, output may be requested in either 
the reference frame of a particular body, or an “observer” frame. To 
specify the frame of a particular body, use the body_name entered in the 
febody .definitions namelist. To specify the observer frame defined in 
the &observer_motion namelist, use ’observer’. 

slice_group( : ) = 1 

This assigns this slice to a particular group number. Within a group, 
slice locations must be given in ascending order. 

chord_dir(:) = 1 

This is the direction of local chord relative to the direction from leading 
edge to trailing edge, in the slice plane. The value 1 indicates local chord 
in direction from leading edge to trailing edge. The value —1 indicates 
local chord in direction from trailing edge to leading edge. Determination 
of the leading and trailing edges is described below. 
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te_def ( : ) = 1 


This is the number of points or line segments to consider when defining 
the trailing edge of the slice (see Fig. B2). A value of 1 defines the 
trailing edge as the aft- most point. This is best for sharp trailing edges. 
A positive number greater than 1 initiates a search over the aft-most 
te_def segments for corners, after which the trailing edge is taken as 
the average coordinate over all the detected corners. Two corners are 
assumed to be the desired number, and warnings are output if only 
one or more than two are found. The value of te_def must be chosen 
judiciously. It should be large enough to allow both corners to be found 
but not so large as to cause excessive searching or for any non-trailing 
edge corners to be found. A positive value of te_def is best for and 
recommended only for squared-off trailing edges. A negative number 
indicates a parabolic fit of the aft-most abs(te_def) points, which is 
best for rounded or blunted trailing edges. 

le_def ( : ) = 30 

This is the number of points to consider when defining the leading edge 
of the slice (see Fig. B3). A value of 1 defines the leading edge as the 
forward-most point. Use this if nothing else works or for special cases. A 
positive number indicates a search over the forward-most le_def points 
for the one that has the maximum distance from the previously deter- 
mined trailing edge. A positive number for le_def is generally the best 
choice provided that the trailing edge can be accurately located. A nega- 
tive number indicates a parabolic fit over the forward- most abs(le_def) 
points. 

corner_angle ( : ) = 120.0 

This is used in conjunction with a te_def greater than 1. Angles between 
adjacent sliced segments that are less than corner.angle degrees will be 
considered a corner between the two segments. For squared-off trailing 
edges, two and only two corners should be detected; warnings are output 
if only one or more than two are found. 

use_local_chord = .true. 

Use the computed local (sectional) chord based on the computed lead- 
ing edge and trailing edge locations to normalize the sectional force 
and moment data. When .false., the value of x_moment_length in 
&f orceunoment_integ_properties will be used instead of the locally 
computed chord. 

tecplot_slice_output = .true. 

This outputs the sliced data to a formatted Tecplot™ hie that is named 
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[project_rootnamej_slice.dat. This file can become very large for 
unsteady flows with frequently written data at many slice locations. 

output_sectional_f orces = .true. 

This outputs detailed force and moment data for each slice to a formatted 
file, [project_rootname] ,sectional_f orces. This file contains force 
and moment data, like that in the [project_rootname] .forces file, for 
each and every slice. In addition, it contains geometrical data for each 
slice (leading and trailing edge coordinates, moment center, etc.) This 
file can become very large for unsteady flows with frequently written data 
at many slice locations. The data in the file, especially the geometry 
data, can be useful to assess whether the slicing is working as expected. 

slice_initial_coords = .false. 

This allows faster slicing for some cases by only computing slice inter- 
polation coefficients once. 

custom_transf orm(l , 1 , 1 : 4) = 1.0, 0.0, 0.0, 0.0 

This is a user-specified transform matrix to allow slicing in a custom 
coordinate system. 

output_in_slice_coords ( : ) = .false. 

This outputs sliced data in the user-specified coordinate system. The 
default outputs the data in the slice_frame, which is only available if 
custom.transf orm is set. 

Important Considerations for Determination of Leading And Trail- 
ing Edges Determining the locations of airfoil leading and trailing edges 
is especially important for rotorcraft applications where airloads are usually 
examined (and provided to a CSD code, if applicable), in an airfoil section- 
aligned coordinate system. The leading and trailing edge points determine the 
orientation of this section aligned coordinate system. In the section-aligned 
system, the local x coordinate is aligned with the local chord, positive in the 
direction from the leading edge to the trailing edge. The local span direction is 
defined by the moment centers at the slicedLocation points, positive in the 
direction of increasing slice_location. The local normal direction is defined 
as the cross product of the local chord vector and local span vector. When 
slicing boundary data, the computed forces are computed in both the selected 
frame of reference (see slice_frame) and in an airfoil section aligned system. 
If the data in the section-aligned system is irrelevant to you, then you do not 
need to worry about choosing the detection parameters carefully; the default 
values should be reasonable. However, if resolution of forces and moments 
into a section- aligned system is important to you, then there are a number of 
things that should be considered: 
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1. Make sure the chord direction chord.dir is correct; the default is that 
going from the leading edge to the trailing edge is the same as traveling in 
the positive “chordwise” coordinate direction. For most applications this 
is the usual situation; however, the convention for rotorcraft applications 
is the opposite, requiring chord.dir = -1. 

2. Since the best option for determining the leading edge uses the trailing 
edge location (le_def > 1), care should be taken to get the trailing edge 
correct. For sharp trailing edges, this is very simple since the default of 
te_def = 1 (i.e. , use the aft-most point) is the best option. However, 
smoothly blunted or squared-off trailing edges are more difficult. When 
the boundary surface of an unstructured mesh is sliced, the resulting 
section will be comprised of line segments determined by the intersec- 
tion of the specified plane and the edges of the surface triangles. These 
segments and the points that make up the segments will not usually be 
the same as the surface points; typically there are more segments and 
points arising from intersected triangles, as illustrated in Fig. Bl. This 
greater point count should influence the selection of te.def and le.def 
values. You will need enough segments (te_def and le_def) to ensure 
that both corners are detected, but not so many that other, non trailing- 
edge corners (if present) are detected. Another parameter that may be 
of use to aid in the detection of corners is the corner .angle; corners 
with angles larger than corner.angle between adjacent segments will 
require a larger value of corner.angle for detection. 

The resulting section corresponding to the slice depicted in Fig. Bl is 
shown in Fig. B2, where the view is zoomed in to the trailing edge 
region. The aft-most 8 segments (of the approximately 30 segments in 
this view) are shown in red. The computed trailing edge locations using 
two different te.def values are shown. The minimum te.def value at 
this particular station to pick up both corners would be 8, but a value of 
20 was used in case another slice required more segments. If the blade 
was pitched downward rather than upward, then the point chosen by 
te.def = 1 would be the lower corner, rather than the upper corner as 
shown. Thus, when pitching up and down, te.def = 1 with squared-off 
trailing edges can lead to jumps in the trailing edge position as the section 
transitions from pitch up to pitch down. Depending on the thickness of 
the trailing edge, this can lead to jumps in the geometric pitch angle of a 
few tenths of a degree. To avoid this, the option slice.initial.coords 
= .true, will reuse the leading and trailing edges determined from the 
initial grid definition, rather than the current, displaced grid location. 

3. Smoothly-blunted (rounded) trailing edges should be done with either 
te.def = 1 (aft-most point) or via a parabolic fit of the aft-most 
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abs(te_def) points; the latter option is probably better in general but 
will require some experimentation for the particular case at hand to 
choose the optimal number of points over which to fit the parabola. 

4. The leading edge is typically easier to determine, if a good trailing edge 
position has already been found. The default value of le_def = 30 
(search the 30 forward-most points for the one with the greatest dis- 
tance from the trailing edge location) should do a decent job for most 
cases. 

Figure B3 shows a sliced section, zoomed in to the leading edge region. 
The forward-most 20 segments (of the approximately 30 segments in this 
view) are shown in red. The computed leading edge locations using two 
different le_def values are shown. In this case, both results are fairly 
close but le_def = 30 has picked out the true leading edge (as judged 
from the leading edge geometry at zero pitch angle). 

5. The leading edge and trailing edge detection schemes can be somewhat 
sensitive to the input choices. For cases that rely on accurate resolution 



Figure Bl: View looking upstream from the trailing edge of a rotor blade 
mesh; the light-colored region is the squared-off trailing edge; the red line 
shows the location where an x=constant slice will be taken; black circles 
indicate surface grid points on the trailing edge. 
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of forces and moments into section- aligned coordinates (e.g., rotorcraft), 
it is wise to spend some time up front to make sure that things are 
coming out as expected. To do this, inspect the [project_rootname] 
,sectional_f orces hie for a particular slice station; at each station the 
computed leading and trailing edge coordinates will be output. Plot 
the corresponding station from the [project_rootnamej_slice.dat, as 
done above, and make sure the computed coordinates are the correct 
ones. If many stations are sliced, it is impractical to inspect all of them 
in this manner, but it is good practice to spot check at least a few 
stations. For moving-geometry cases, try first running the case with 
bodyunotion_only = .true, in the feglobal namelist. This will allow 
output of the [pro j ectxrootname] ,sectional_f orces and [pro j ect_rootname] 
_slice.dat hies without the expense of a how solve or mesh deformation; 
for spot checking you may want to have the slicing done infrequently, per- 
haps using fewer stations than ultimately desired, as these output hies 
can be huge. 

6. While the [project_rootname] ,sectional_f orces can be useful for 
spot checking, the data in the hie is not in a format that is amenable to 
plotting. The Fun 3D distribution utils/Rotorcraft directory con- 



Figure B2: Sliced section corresponding to Fig. Bl; zoomed in to the 
trailing edge region. 
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tains a utility code that will read in both the hies slice. info and 
[project_rootname] ,sectional_f orces to output Tecplot™ hies, for 
each slice group, containing force and moment data in the section-aligned 
coordinate system, as well as geometry data (leading edge, trailing edge, 
quarter-chord coordinates, and pitch angle). 

7. After making sure that the leading edge and trailing edge positions are 
being computed correctly, you may want to turn oh one or both of 
the [projectvrootname] .sectional_f orces and [projectvrootname] 
_slice.dat hies unless needed. For instance, in rotorcraft applications 
with coupling to external CSD codes, although the blade boundary sur- 
faces must be sliced to generate the aerodynamic loads data for the CSD 
code, this information is actually passed to the CSD code by another hie; 
the [project_rootname] ,sectional_f orces and [project_rootname] 
_slice.dat hies are not used. 

8. Although the slicing process will work for multi-element airfoils, at this 
time the computation of the leading edge and trailing edge is only done 
for the entire section, not each element individually. 



0.4 0.45 0.5 


X 

Figure B3: A sliced section, zoomed in to the leading edge region. 
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B.4.30 &:overset data 


This namelist specifies information for overset grid simulations. The overset 
option may be used with either static or dynamic meshes. In either case, 
an initial overset connectivity file, corresponding to the configuration at t=0, 
must be provided. Connectivity files must be in the SUGGAR++ ‘dci’ format, 
or, if using the dci_io option (see below), in the FUN3D ‘dcif’ format. A 
conversion utility (utils/dci_to_dcif ) is provided to convert from the dci 
format to the dcif format. The initial overset connectivity file must be named 
[project] .dci (or [project] .dcif if using the dci_io option). For dynamic 
meshes, the user may elect to provide precomputed connectivity files for each 
time step, in which case the files must be named [project] l.dci for time step 
1 at t=At, [project] 2. dci for time step 2 at t=2At, and so on. The naming 
convention is the same when using the dci_io option, except the file extension 
is .dcif rather than .dci. 


&overset_data 


overset_f lag 

= 

.false . 

dci_on_the_f ly 

= 

.false . 

dci_period 

= 

huge ( 1 ) 

reset_dci_period 

= 

.false . 

dci_freq 

= 

1 

dci_dir 

= 

1 1 

reuse_existing_dci 

= 

.false . 

skip_dci_output 

= 

.false . 

dci_io 

= 

.false . 

dci_io_nproc 

= 

1 


/ 


overset_flag = .false. 

When .true., overset mesh capability is enabled. 

dci_on_the_f ly = .false. 

This controls whether overset connectivity is computed as the grid moves, 
or whether overset connectivity has been pre-computed for each grid 
position and is available to read in. Ignored if overset.flag = .false, 
and oversetxrotor = .false, in the &rotor_data namelist. 

dci.period = huge(l) 

This controls the period (in terms of timesteps) at which the dci counter 
is reset. At time step dci_period+l, the flow solver will read overset 
data from the dci file [project] l.dci, corresponding to time step 1 at 
t=At. (Note: if dci_io = .true., the corresponding file name would 
be [project] l.dcif). For example, if the simulation involves rotation 
through 360 degrees with a time step corresponding to 1 degree per 
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step, set dci.period = 360, and, if the user is providing precomputed 
dci files, the final one provided would be named [project] 360. dci and 
would correspond to the 360 degree position. If instead the same 360 
degree rotation was run with 0.5 degrees per step, set dci.period = 720 
and the final dci hie would be [pro j ect] 720. dci, again corresponding to 
the 360 degree position. When using the dci_on_the_f ly option, connec- 
tivity hies are computed and written for the hrst dci_period timesteps, 
after which the code begins reading and reusing the connectivity hies. 
The default value implies that the motion is not periodic and therefore 
the dci counter is never reset. Ignored if overset_flag = .false, and 
oversetxrotor = .false, in the &rotor_data namelist. 
reset_dci_period = .false. 

When .true., allows dci.period to be reset to a different value for 
restarting with a different time step. 

dci.freq = 1 

This controls how frequently the dci data is updated, either by compu- 
tation within the how solver, or by reading a new dci hie. Dci data is 
updated every dci_freq time steps. 

dci.dir = ’ . 1 

This is the directory where dci hies are located. Note: A trailing for- 
ward slash (/) is automatically added and should not be included in the 
directory name. 

reuse_existing_dci = .false. 

When .true., allows the computation of dci data to be skipped if a dci 
hie for the current time step already exists. This option is typically used 
in conjunction with dci.period, so that dci hies are computed on the hy 
for the hrst dci_period time steps, and then hies are reused for all subse- 
quent periods of grid motion, without having to change dci_on_the_f ly 
in between. Ignored if dci_on_the_f ly = .false.. 

skip_dci_output = .false. 

When .true., the solver will not save the dci data to a hie. Ignored if 
dci_on_the_f ly = .false.. 

dci_io = .false. 

When .true., dci hies are read from disk with a dedicated rank (proces- 
sor) to help mask communication with computation. 

dci_io_nproc = 1 

When dci_io = .true., this specihes the number of ranks to use for 
loading of dci hies. 
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B.4.31 &rotor data 


This namelist controls high-level rotor simulation settings. Eventually, this 
namelist may subsume rot or. input. 

&rotor_data 

comprehensive_rotor_coupling = 'none' 
overset_rotor = .false. 

/ 


comprehensive_rotor_coupling = ’none’ 

This controls whether the code is to be coupled to a rotorcraft compre- 
hensive code, and if so, which one. 

‘ none ’ not coupled. 

< camrad J coupled to CAMRAD-II. 

‘rcas’ loosely coupled to RCAS. 

‘rcas-tight’ tightly coupled to RCAS. 

‘fsi’ tightly coupled to DYMORE. 

overset_rotor = .false. 

This controls whether overset meshes are used for moving rotor simula- 
tions. When .true., the rotor motion is governed by the rotor. input 
file. 
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B.4.32 &adapt metric construction 

This namelist controls how the metric is formed for metric-based mesh adap- 
tation. More details on grid adaptation can be obtained in section 8. The 
metric is either feature-based or output-based and is constructed through a 
common framework. 

For a feature-based metric, adapt_f eature_scalar_key specifies the scalar 
field S. See the description of adapt _feature_scalar_key for a list of available 
options. The intensity / at each node is constructed from S at each node with 
the adapt_f eature_scalar_f orra method applied across each incident edge. 
See the description of adapt_f eature_scalar_f orm for a list of available edge 
operators and how they are gathered to the nodes. The feature-based isotropic 
scaling of the grid is h/h 0 , 


h 

h 0 



(Bl) 


where T is the adapt_output_tolerance, u is the adapt.exponent, and g 
is the adapt _max_edge_growth. For feature-based adaptation, the setting 
adapt_output_tolerance is chosen to scale /, and its value will depend of 
the choice of adapt_f eature_scalar_key and adapt_f eature_scalar_f orm. 
Trial and error is required to determine an adapt_output_tolerance (T) set- 
ting that scales I to be greater than one in regions that have the features that 
require grid refinement. Therefore, it is case specific. 

For an output-based metric, the intensity is given as 
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where R is the flow residual, R x is the adjoint residual, Q is the flow solu- 
tion, A is the adjoint solution, the " accent is a high-order reconstruction or 
interpolation, and the " accent is a linear reconstruction or interpolation. Re- 
construction or interpolation is selected with adapt_error_estimation. See 
Park [30] for details. The output-based isotropic scaling of the grid is h/h 0 , 
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where u is the adapt .exponent and g is the adapt _max_edge_growth. T is the 
adapt.outputvtolerance divided by the number of nodes when it is positive. 
When adapt.output.tolerance is negative, T is -adapt.output.tolerance 
times the average or median / based on adapt_statisti.cs. 

The anisotropic feature-based and output-based metrics are constructed 
from h/ho in the same manner. The adapt _hessian_method is applied to the 
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adapt Jies si an_key scalar field to compute the Hessian H . The symmetric H 
is decomposed into eigenvalues A and eigenvectors X. The eigenvectors of H 
form the eigenvectors of the metric M, which are also the principle directions 
of M. The eigenvalues of M are related to the spacing in each of the principle 
directions by A = 1/h 2 , which start as the absolute value of the eigenvalues of 

H, 


M = X 


|Ai| 

|a 2 | 

I A3 


X 1 = X 



X T . (B4) 


The aspect ratio of M is limited by controlling the two smallest eigenvalues to 
be (1/adapt _max_anisotropy) 2 times the largest. The eigenvalues of M are 
scaled so that the largest eigenvalue is (h*(/i/h 0 ))~ 2 , where h* Q is an estimate of 
the current isotropic grid size given by adapt_current_h_method. The grada- 
tion of the M is limited with adapt .gradation if adapt .gradation is positive. 
If adapt.coraplexity is positive, the complexity (an integral measure of the 
adapted grid size) of M is scaled to match the requested adapt.complexity. 
Finally, if adapt unax.edge.length or adapt unax.edge.length are positive, 
the eigenvalues are limited to bound the spacing of the metric. 

&adapt_metric_construction 


adapt _hessian_key 

= 

1 mach ' 

adapt _hessian_method 

= 

' lsq' 

adapt _max_anisotropy 

= 

1 . 0e6 

adapt _max_edge_growth 

= 

2.0 

adapt _max_edge_length 

= 

-1.0 

adapt _min_edge_length 

= 

-1.0 

adapt _output_tolerance 

= 

-0.5 

adapt _complexity 

= 

-1.0 

adapt _gradat ion 

= 

-1.0 

adapt _err or .estimation 

= 

' embed' 

adapt .statistics 

= 

'median' 

adapt .exponent 

= 

0.2 

adapt _feature.scalar.key 

= 

' density 

adapt _feature.scalar.form 

= 

' delta' 

adapt_feature.length.exp 

= 

0.5 

adapt .inter sect .met ric.in.time 

= 

.false . 

adapt.metric_from.file 

= 

1 1 

adapt .export .metric 

= 

.false . 

adapt _twod 

= 

.false . 

adapt.verbose 

= 

.false . 

adapt.export_feature_scalar.key 

= 

' none ' 
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none 


adapt. visualize.metric 
adapt_current_h_method = ' edge ' 

adapt_current_h_gradation = 1.5 


adapt _hessian_key = ’ mach’ 

This variable is used to define anisotropic Hessian, 

'mach’ is Mach number. 

'pressure’ is pressure. 

‘ entropy ’ is entropy. 

'temp’ is temperature. 

'density’ is density. 

' vorticity-magnitude ’ is the magnitude of the vorticity vector, 
adapt Jiessianunethod = ’lsq’ 

This is the mathematical method used to recover the Hessian, 

'lsq’ applies a least-squares gradient calculation twice. First it com- 
putes gradients via least-squares. Then the Hessian is computed by a 
second application of least-squares to the reconstructed gradient. 

'green’ use a Green variational approach, see Alauzet and Loseillc [54] 
for details. 

' kexact ’ reconstructs the Hessian with a k-exact approach. See Barth 
[55] for details. 

'grad’ is volume- averaged element-based gradients, applied twice. 

'mesh’ implies the metric of the current grid for use in testing grid 
adaptation mechanics or maintaining the current anisotropy. 

adapt_max_anisotropy = 1.0e6 

This is the upper limit of the largest to smallest spacing in the metric, 
adapt _max_edge .growth = 2.0 

This is a limit on the change of isotropic grid size of the metric, where 
adapt _max_edge .growth is g and the change in isotropic grid size be- 
tween the next and current grids is h/ho- The feature-based metric is 
limited to h/ho < 9 and the output-based metric is limited to l/g < 
h/ho < g. A value of 1 would constrain feature-based metric to refine- 
ment only. This setting limits the change in grid size for subsequent 
output-adapted grids and can be increased for more benign simulations 
or near output-adapted grid convergence. 
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adapt_max_edge_length = -1.0 


This sets a maximum allowable spacing of the metric. It is a grid- and 
problem-dependent value and should be expressed in grid units. A neg- 
ative value is unlimited. 

adapt_min_edge_length = -1.0 

This sets a minimum allowable spacing of the metric. It is a grid/problem 
dependent value and should be expressed in grid units. A negative value 
is unlimited. 

adapt_output_tolerance = -0.5 

This is the error request for output-based adaptation and the scaling of 
the scalar term for feature-based adaptation. Feature-based adaptation 
requires a positive number. Output-based adaptation can be negative 
to indicate a relative error reduction or positive to indicate an absolute 
error request. It is difficult to choose a good value for this tolerance, see 
adapt_complexity for a more intuitive way to request the adapted grid 
size. 

adapt_complexity = -1.0 

This is the target complexity for the metric. The complexity of a metric 
(C) is an integral measure of the density of the metric field, 

C= [ \J det(M) dO, (B5) 

where hi is the computational domain. This option is intended to allow 
a user specification of the number of nodes in the adapted grid by uni- 
formly scaling the metric to set its C to adapt_complexity. There is a 
difference between the requested complexity and the number of nodes in 
the adapted grid, which is examined by Park et al. [56] This is because 
the requested complexity is a continuous measure, but the metric is dis- 
crete. Also, the adaptation mechanics produce a grid that is near, but 
does not exactly match, the metric. Adjust the requested complexity 
manually to obtain the desired grid size if the grid is smaller or larger 
than expected. As detailed in reference [56], the ratio of nodes to com- 
plexity approaches two for 3D grids and a half for 2D grids. 

adapt .gradation = -1.0 

This is the allowable gradation of spacing between adjacent metric ten- 
sors. [57] A positive value activates gradation control, which should have 
parameter in the range [1.1, 2.0]. A negative value deactivates this op- 
tion. A smaller value produces a more gradual spatial variation of the 
spacing request, e.g., a value of 1.0 indicates no variation and would 
result in a uniform grid. 
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adapt_error_estiraation = ’embed’ 

This selects the method used for error estimation for output-based adap- 
tation, 

‘ embed ’ uses a uniformly refined grid and interpolated solution to es- 
timate the output error. [30, 58] Warning: This option requires a large 
amount of memory to construct the embedded, uniformly refined grid. 

'single’ uses the current grid and reconstructed solution to estimate 
the output error. It requires much less memory than ’ embed ’ but does 
not provide an improved estimate of the functional. [30] 

'opt-goal’ is the optimal goal-oriented metric. [59] It has the same 
memory requirements as ’single’ and requires the namelist option 
adapt_complexity to be set. It is only recommended for steady Eu- 
ler flow. 

adapt .statistics = ’median’ 

This selects the method used for determining the intensity / level to 
equidistribute, 

'median’ uses the median of the error estimate intensity I to convert a 
relative error tolerance of a negative adapt.output.tolerance into an 
absolute tolerance. This is useful when there are a few, extremely large 
error estimates that corrupt the average. 

' average ’ uses the average of the error estimate intensity / to convert 
a relative error tolerance of a negative adapt.output.tolerance into an 
absolute tolerance. This is provides better equidistribution when the 
error estimate is well behaved. 

adapt .exponent = 0.2 

This is the exponent on error estimate to map local error to a change 
in grid spacing. It is based on an a priori spatial error convergence 
estimate. [58] 

adapt_f eature_scalar_key = ’density’ 

This is the “key” flow variable (feature) on which to adapt for feature- 
based adaptation. It forms the scalar held S at each node based on, 

'mach’ is Mach number. 

'pressure’ is pressure. 

' entropy ’ is entropy. 

'temp’ is temperature. 

'density’ is density. 

' vorticity-magnitude ’ is the magnitude of the vorticity vector. 
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adapt_f eature_scalar_f orra = ’ delta’ 

This is the method to calculate feature-based refinement indicator from 
the adapt_f eature_scalar_key scalar field S. The following terms are 
computed for each edge in the grid I e and the nodal adaptation intensity 
is the maximum edge value for all edges incident to a node, 

In = max ( J e ) , (B6) 

eEn 

where e denotes each edge incident to node n. The S subscripts 1 and 2 
denote the value at each end point of an edge. The edge terms are, 

‘delta’ is the S jump across the edge, I e = \S 2 — <Sj|. 

‘delta-1’ is the S jump across the edge times the edge length l to the 
adapt_f eature_length_exp power p, I e = l p \S 2 — SjJ. 

‘ average- 1 ’ is the average S of the two nodes of an edge times the edge 
length /, I e = |(S' 2 + Sj). 

‘ratio’ is the ratio of the largest to the smallest S at the edge nodes, 

I e — max(|S' 2 /S'i|, |S'i/S' 2 |) . 

‘max’ is the largest S at the nodes of the edge, I e = max(|S' 2 |, |Si|). 

‘ none ’ will not use scalar term. It is uses the Hessian only. 
adapt_f eature_length_exp = 0.5 

This is the exponent for use with adapt_f eature_scalar_f orm = ’ delta-1 ’ . 
adapt_intersect unetric_in_time = .false. 

This will export a metric intersected over a window that includes each 
time step of the current run. It is used for fixed-point adaptation of 
time-accurate simulations. [59] 

adapt _metric_from_f ile = ’ ’ 

This reads the metric from this hie instead of computing it when it is 
blank. 

adapt_export_metric = .false. 

This exports the metric for external grid adaptation tools. 
adapt_twod = .false. 

When .true., compute a 2D metric from a one cell wide 3D grid contain- 
ing a single layer of spanwise prism elements between symmetry planes. 

This is required when a 2D adaptation method is selected but the grid 
is actually a one cell wide 3D grid, because the adjoint does not have a 
2D specific mode. 
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adapt.verbose = .false. 

When .true., this option reports more information during the error es- 
timation process. This can be helpful for finding the source of NaNs. 

adapt .export _f eature_scalar_key = ’none’ 

This is the export format for the feature scalar key, intensity /, and new 
isotropic size request h/ho. It can be used for visualization or compiling 
statistics. It may be helpful for gaining insight into a setting for the 
adapt_output_tolerance T that targets a specific feature. The hie name 
root is [project_rootnarae] _key. The formats available are, 

'none’ will not export. 

‘ cgns ’ is CGNS format, requires Fun 3D to be configured with a CGNS 
library. 

‘fvuns’ is FieldView C-binary (Fortran stream) format. 

‘VTK’ is legacy VTK format. 

‘ csv’ is a comma separated value format. 

'tec’ is a single image ASCII tecplot format. 

‘raw.ascii’ is a single image raw ASCII space separated format 
adapt_visualize_metric = ’none’ 

This is the format to export the metric for visualization, 

'none’ will not export. 

‘ cgns ’ is CGNS format, requires Fun 3D to be configured with a CGNS 
library. 

‘fvuns’ is FieldView C-binary (Fortran stream) format. 

'VTK’ is legacy VTK format. 

'csv’ is a comma separated value format. 

‘raw.ascii’ is a single image raw ASCII space separated format, 
adapt .current _h_method = ’edge’ 

This is the method to estimate the current spacing of the grid, 

‘ edge ’ will use the shortest incident edge at a node. 

‘ implied ’ will use the largest eigenvalue of adjacent element implied 
metrics. 

adapt .current _h_gradat ion = 1.5 

This limits the gradation of the current spacing estimate by requiring it 
to be larger than this ratio of its neighbor’s spacing estimate. 
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B.4.33 &adapt mechanics 

This namelist contains variables that control how grid adaptation is per- 
formed. More details on general metric-based grid adaptation can be ob- 
tained in section 8. This namelist also contains variables to control specialized 
line adaptation adapt.library = ’line' and shock fitting line adaptation 
adapt.library = ’ sflineU 

Variables with the ladapt_ prefix control line adaptation and variables 
with a sf line, prefix control shock fitting line adaptation. These specialized 
ID adaptation methods originated in the LAURA code and have a number of 
requirements that are described in the LAURA User’s Manual. [60] The grid 
origin must be structured and all nodes assigned to a unique line. All lines 
must have the same number of nodes. The outer boundary (opposite solid 
walls) can be moved in or out to align with a developing bow shock and the 
distribution of points across the boundary layer can be adjusted to recover a 
target cell Reynolds number. If the grid has prisms grown off a solid surfaces 
then the distribution of prism heights can be adjusted to recover a target cell 
Reynolds number at the wall while retaining the the original spacing at the 
top of the prism stack. 

Variable names beginning with sfline. control how shock fitting meshes 
are adapted. Currently the shock fitting is only available with line adaptation 
which is engaged by specifying adapt.library = 5 sflineU The variables 
ladapt_re_cell, ladapt.epCLgrd, ladapt_fstr, and ladapt_g_limiter are 
also active with shock fitting. 


feadapt .mechanics 


adapt.library 

= 

' refine 

adapt.project 

= 

1 1 

adapt _f reezebl 

= 

-1.0 

adapt.cycles 


2 

adapt _bamg_ command 

- 

' bamg 1 

adapt _bamg_geometry_f ormat 

= 

' amdba ' 

ladapt.f sh 

= 

0.8 

ladapt.f str 

= 

0.75 

ladapt.f ctr jmp 

= 

1.05 

ladapt_re_cell 

= 

1. 

ladapt_beta_grd 

= 

0. 

ladapt_epO_grd 

= 

0. 

ladapt.max.di stance 

- 

l.e+06 

ladapt.jumpf lag 

- 

2 

ladapt.f req 

= 

0 

1 adapt _max 

= 

1000 

ladapt_g_limiter 

= 

0. 

sf adapt _f sbuf f r 

= 

3 

sf adapt _ceqinc 

= 

0.5 
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sf adapt _shkdtct 
sf adapt _f sf racO 
sf adapt _f sf raci 


= l.Oe-Ol 
= l.Oe+OO 
= l.Oe-Ol 


adapt .library = ’ refine/one ’ 

This is the adaptation library to call from Fun 3D. The options are, 

‘ refine/one ’ is the refine tetrahedral metric-based adaptation library. 
See Park [30] for a detailed description. This library lacks a 2D specific 
mode. 

‘ refine/two ’ is a version of the refine adaptation library that is still 
undergoing development. It is based on original version of refine with 
some ideas from Michal and Krakos. [61] This library emulates a 2D ca- 
pability by adapting a 3D grid with one layer of spanwise prism elements 
between symmetry planes. 

‘meshsim’ is the Simmetrix MeshSim M adaptation library. 

‘ bamg ’ is the BAMG [4] 2D metric-based adaptation library. The 2D 
metric and solution hies in BAMG format will be exported from a 3D 
grid with one layer of spanwise prism elements between symmetry planes. 
The BAMG executable will be run in the ../Flow directory by using its 
native .ambda or .msh formats, see adapt.bamg.geometry .format. 

'line’ is line-based adaptation [60] for structured grids. 

‘ sfline’ is shock-fitting line-based adaptation for structured grids. 

‘ interpolate’ will linearly interpolate the projectxrootname solution 
to an existing adapt .project grid without adaptation by using the ap- 
proach of Shenoy. [62] 

adapt.project = ’ ’ 

This is the project name for exporting the adapted grid and solution. An 
empty string appends _R to the projectxrootname from the feproject 
namelist. 

adapt_freezebl = -1.0 

This prevents modification of the grid within this distance of solid wall 
boundaries. It is used to preserve an existing boundary layer grid struc- 
ture and is specified in grid units. A negative value will disable freezing. 
A distance that equates to a y + of approximately 300, the middle of 
the log-layer is recommended. To reduce size inconsistencies between 
the frozen and adapted zones, chose a adapt_freezebl where bound- 
ary layer element aspect ratio matches the adapt _max_anisotropy in 
the feadapt _metric_construction namelist. For more discussion on 
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this technique, see Park and Carlson. [63] This option is only used by 
adapt .library = ’ refine/one ’ . 

adapt.cycles = 2 

This is the number of adaptation passes. Choosing more cycles will 
produce a grid that better matches the metric, but can increase the time 
required for adaptation. This option is only used by adapt.library = 
’ refine/one ’ . 

adapt _bamg_command = ’ bamg’ 

This is the system command to execute BAMG. It may include the full 
path or command line arguments. 

adapt_bamg_geometry .format = ’ amdba’ 

BAMG geometry hie format 

‘amdba’ specifies -b [project_rootname] .ambda as the BAMG geome- 
try source. This will spline current boundary nodes to form the geometry 
of the domain boundary. It is approximate, but less likely to fail than 
.msh hie boundary reconstruction. 

‘msh’ specifies -b [projectxrootname] .msh as the BAMG geometry 
source. This will access the original geometry .msh hie to define the 
domain boundary, but BAMG may have problems with boundary recon- 
struction. 

ladapt_fsh = 0.8 

This is the fraction of the distance between the body and the opposing 
boundary along a line of nodes where the captured shock is situated. 

ladapt_fstr = 0.75 

This is the fraction of edges along a line that are intended to resolve the 
boundary layer. 

ladapt_f ctrjmp = 1.05 

This is the property ratio used to detect the shock when marching from 
the freestream toward the body. It is assumed the how above the shock 
is uniform and the property ratios across edges along the line remain 
equal to one until the shock is encountered. 

ladapt_re_cell = 1. 

This is the target cell Reynolds number based on the speed of sound 
used to define the edge length An of the hrst edge leaving the wall. 
re ce u = pAnc/ p. 
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ladapt_beta_grd = 0. 

This is an exponential grid distribution parameter. Any value greater 
than 1 will override adaptation. If it is used to override adaptation to 
local flow, the recommended value is 1.15. 

Iadapt_ep0_grd = 0. 

This is a grid clustering factor to pull nodes into the captured shock. 
A minimum value of 0 produces no clustering. A maximum value of 
6.25 produces greatest clustering. Larger values can produce negative 
volumes. 

ladapt_max_distance = l.e+06 

This is the maximum distance in grid units the outer boundary can be 
moved away from the body. This parameter is useful when adapting to 
the shock in the wake, where the adapting grid may become excessively 
skewed. This value then effectively defines the maximum length of the 
wake domain. 

1 adapt _jumpf lag = 2 

This is an integer flag used to select the method of shock detection, 

‘O' is no movement of outer boundary. Resolution in the boundary layer 
is adjusted to recover target ladapt_re_cell. 

‘ 1 J uses pressure as sensing parameter. 

‘ 2 J uses density as sensing parameter. 

‘ 3 J uses temperature as sensing parameter. 

‘4 J scales all edges along the line by a factor equal to ladapt_f ctr jmp. 
1 adapt _freq = 0 

This is the number of relaxation steps between calls to line adaptation. 
The value 0 prevents line adaptation. 

ladapt_max = 1000 

This is the maximum number of calls to line adaptation permitted. 
ladapt_g_limiter = 0. 

This parameter insures a minimum mesh size does not get too big on a 
line and cause local skewing. It must be a positive number to engage. 

sf adapt_f sbuffr = 3 

This is the number of buffer nodes between the freestream boundary and 
the fitted shock. Zero buffer nodes make the freestream boundary the 
shock fitting surface, three buffer nodes moves the shock fitting surface 
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three nodes into the interior of the computational domain relative to the 
freestream boundary. 

sf adapt_ceqinc = 0.5 

This is the shock fitting compatibility equation influence coefficient. A 
value of 0.0 means that shock fitting is controlled by the continuity equal 
to the compatibility equation, a value of 1.0 means that the shock fitting 
is controlled by momentum equation compatibility equal to the compat- 
ibility equation, and a value of 0.5 means that shock fitting is equally 
controlled by the continuity and momentum compatibility equations. 

sf adapt_shkdtct = 1.0e-01 

This is the shock fitting shock-boundary interaction detector coefficient. 
This parameter controls when the shock is considered to be interacting 
with the shock fitting boundary nodes and determines when the bound- 
ary begins to be fitted to the shock. The value is one minus the local 
relative density jump below which the shock is not considered to be in- 
teracting with the boundary. Increasing this parameter decreases the 
sensitivity of the sensor and decreasing this parameter increases the sen- 
sitivity of the sensor. 

sf adapt_f sfracO = 1.0e+00 

This is the shock fitting initial freestream velocity boundary velocity frac- 
tion. When the bow shock has not yet reached the freestream boundary, 
the shock fitting equations are not valid. However, the code allows the 
freestream boundary to initially move towards the body at some fraction 
of the freestream boundary velocity. A value of 0.0 freezes the freestream 
boundary until the shock reaches it, a value of 1.0 moves the freestream 
boundary at the freestream velocity until the shock reaches it, and a 
value in the range (0.0, 1.0) moves the freestream boundary towards the 
body at freestream total velocity*sf adapt_f sfracO. 

sf adapt_f sfraci = 1.0e-01 

This is the shock fitting interaction freestream velocity boundary veloc- 
ity fraction. When the bow shock has been determined to be interact- 
ing with the freestream boundary, the shock fitting equations are not 
valid all along the shock. However, the code allows the initial interac- 
tion speed of the shock with the freestream boundary to be scaled back 
at some fraction of the freestream boundary and/or shock velocity. A 
value of 0.1 constrains the freestream boundary to move at a fraction 
of the freestream velocity and a value in the range (0.0, 1.0) moves the 
freestream boundary towards/away from the body at freestream total 
velocity* sf adapt _f sf rac i . 
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B.4.34 &massoud output 

This namelist controls the output of hies for interaction with the MDO pack- 
ages (e.g., design, aeroelastics) . In a design setting, these hies contain the 
information necessary to parameterize the surface grid(s). The command- 
line option --write_aero_loads_to_f ile is required to output the aeroelas- 
tics hie [projectvrootname] _ddfdrive_bodyN.dat and the command line op- 
tion --write_massoud_f ile is required to output the design parameterization 
hie [project_rootnamej_rnassoud_bodyN.dat for each of the N body groups 
present. 

&massoud_output 


n_bodies 

= 

0 




nbndry ( : ) 

= 

0 




boundary_list ( : ) 

= 

1 1 




output _initial_st ate 

= 

. false . 



massoud_output_f req 

= 

-1 




massoud_f ile_f ormat 

= 

' ascii ' 



massoud_use_initial_coords 

= 

. false . 



aero_loads_output_f req 

= 

-1 




aero_loads_file_f ormat 

= 

' ascii ' 



include_time_inf o 

= 

. true . 



aero_loads_use_initial_coords 

= 

. false . 



aero_loads_dynamic_pressure 

= 

1.0 




output_transf orm(l , 1 : 4) 

= 

1.0, 

0.0, 

0.0, 

0.0 

output_transf orm(2, 1 :4) 

= 

0.0, 

1.0, 

0.0, 

0.0 

output_transf orm(3, 1 :4) 

= 

0.0, 

0.0, 

1.0, 

0.0 

output_transf orm(4, 1 : 4) 

= 

0.0, 

0.0, 

0.0, 

1.0 

output _scale_f actor 

= 

1.0 




input_transf orm(l ,1:4) 

= 

1.0, 

0.0, 

0.0, 

0.0 

input_transf orm(2 ,1:4) 

= 

0.0, 

1.0, 

0.0, 

0.0 

input_transf orm(3 ,1:4) 

= 

0.0, 

0.0, 

1.0, 

0.0 

input_transform(4, 1 :4) 

= 

0.0, 

0.0, 

0.0, 

1.0 

input _scale_f actor 

= 

1.0 





/ 


nibodies = 0 

This is the number of user-defined bodies. For moving-grid cases, these 
bodies are typically the same as those defined as moving bodies, but that 
need not be the case. 

nbndry ( : ) =0 

This is the number of boundary patches listed for a given body, 
boundary.list ( : ) = ’’ 

This is a list of boundary patch numbers for a given body. Commas and 
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dashes can be used to specify ranges, i.e., ’ 1 , 2 , 5-7 ’ . 
output_initial_state = .false. 

When .true., this causes requested massoud or aero loads data to be 
written for the initial state of the solution in the current run. 

massoud_output_freq = -1 

This is the iteration frequency of massoud output, where the special 
value -1 corresponds to once at the end of a successful run. 

massoud_f ile_f orraat = ’ ascii ’ 

This is the format of the massoud hie; the alternate choice is ’ stream’ 
(C binary). 

'ascii’ is ASCII hie format 

'stream’ is Fortran stream (C binary) format 

massoud_use_initial_coords = .false. 

Write the massoud hie for the x,y,z surface coordinates at t=0. Other- 
wise, use current x, y , z surface coordinates. 

aero_loads_output_freq = -1 

This is the iteration frequency of aerodynamic loads output, where the 
special value -1 corresponds to once at the end of a successful run. 

aero_loads_f ile_f ormat = ’ascii’ 

This is the format of the aerodynamic loads hie; the alternate choice is 
’stream’ (C binary). 

'ascii’ is ASCII hie format 

'stream’ is Fortran stream (C binary) format 

include _time_inf o = .true. 

Write simulation time and strand info to ASCII Tecplot M hle(s). Includ- 
ing time info in the hies makes animation within Tecplot™ very simple. 

aero_loads_use_initial_coords = .false. 

Write the current aerodynamic loads mapped to the x, y, z surface coor- 
dinates at t=0. Otherwise, use current x, y, z surface coordinates. This 
option is only relevant if the grid is moved or changed during the solution 
process. 

aero_loads_dynamic_pressure = 1.0 

The dynamic pressure used to convert force coefficients into forces; the 
default value leaves the output in coefficient form. Note that the input 
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variable output _scale_f actor separately handles scaling of coordinate 
values, so care must be exercised to insure appropriate dimensional forces 
if both are used in combination. 

output.transf orm(l , 1 : 4) = 1.0, 0.0, 0.0, 0.0 

This is a user-specified transform matrix to allow output of aero loads 
in a custom coordinate system; typically used to output aero loads in 
an FEM/CSD coordinate system that differs from the CFD coordinate 
system. Note, at this point in time, this transform is applied to ALL 
bodies that are defined in this namelist. Note: the transform matrix 
should NOT include a scaling factor (e.g. inches to meters); any required 
scale factor is input separately. 

output_scale_f actor = 1.0 

Allows a scaling of the output x,y,z coordinates (e.g. meters to inches). 
Scaling is applied as a multiplicative factor. 

input_transf orra(l , 1 : 4) = 1.0, 0.0, 0.0, 0.0 

This is a user-specified transform matrix to allow input of a new surface 
mesh that is defined in a custom coordinate system; typically used to 
read in a displaced surface defined in an FEM/CSD coordinate for use in 
the CFD coordinate system. Note, at this point in time, this transform 
is applied to ALL bodies that are defined in this namelist. Note: the 
transform matrix should NOT include a scaling factor (e.g. inches to 
meters); any required scale factor is input separately. 

input_scale_f actor = 1.0 

Allows a scaling of the input x,y,z coordinates (e.g. inches to meters). 
Scaling is applied as a multiplicative factor. 
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B.4.35 &sonic boom 

This namelist specifies how near-field pressures are extracted from Fun 3D 
for comparison to wind tunnel measurements, atmospheric propagation to the 
ground by another code, or for boom related adjoint cost functions. When 
nsignals is greater than zero, the pressure signature is output as a Tecplot™ 
file. The number of points in this output file is determined by the number of 
element faces intersected by each user-specified ray, and will span the x-extent 
of the entire mesh at that ray location. 

The rays are rotated about (x_cor,z_cor) by angle.of .attack when the 
variable rotate_ray_by_angle_of .attack is true. 

This namelist is also used with the sonic boom adjoint cost functions 
boom.targ (section 9.2.6) and sboom (section 9.2.7). To form the cost func- 
tion the ../rubber. data file is required for the flow and adjoint solvers. See 
section 6.3 for details on the minimum inputs required for specifying the ad- 
joint cost function. To compute the value of the objective function in the flow 
solver, the — design_run command line option is required. 


&sonic_boom 



nsignals 

= 

0 

y_ray ( : ) 

= 

0.001 

z_ray ( : ) 

= 

0.0 

x_cor 

= 

0.0 

z_cor 

= 

0.0 

rotate_ray_by_angle_of _attack 

= 

. true . 

npoints 

= 

1000 

ray_x_limit .method 

= 

' local 

x_lower_bound 

= 

-1 . e20 

x_upper_bound 

= 

1 . e20 

dp.pinf 

= 

. true . 

p.pinf 

= 

. false 

weight 

= 

. false 


/ 


nsignals = 0 

This is the total number of signal rays. 
y_ray(:) = 0.001 

This is the y value of each ray before angle.of .attack rotation. It is 
dimensioned 1 to nsignals. 

z_ray(:) = 0.0 

This is the z value of each ray before angle.of .attack rotation. It is 
dimensioned 1 to nsignals. 
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x_cor = 0.0 

This is the x center of angle.of .attack rotation. 
z.cor = 0.0 

This is the z center of angle.of .attack rotation 
rotate_ray .by .angle.of .attack = .true. 

When .true., this will rotate the rays by angle.of .attack about x.cor 
and z.cor. 
npoints = 1000 

This is the nominal number of points in each ray that is used to construct 
the cost function. Any points lying outside the domain will be ignored. 
The points are linearly spaced between the lower and upper bound of x. 

ray_x_limit .method = ’local’ 

This is the method used to determine the ^-direction start and end of 
the ray when forming the objective function. If x.lower.bound and/or 
x.upper.bound is specified, then ray_x_limit .method must be set to 
’explicit’. 

‘ local’ sets each ray limit independently by computing the x min and 
x max of all grid cells intersected by the ray. 

'explicit’ explicitly sets the x min and x max of all rays with the 
x.lower.bound and x.upper.bound namelist variables. Only valid for 
adjoint cost function boora.targ. 

x.lower.bound = -l.e20 

This is the explicit x lower bound for ray_x_limit_method= ’ explicit ’ 
in the cost function definition, 
x.upper.bound = l.e20 

This is the explicit x upper bound for ray_x_limit _method= ’ explicit ’ 
in the cost function definition, 
dp.pinf = .true. 

When .true., this will include normalized delta pressure (p — Poo)/Poo in 
tecplot output. 

p.pinf = .false. 

When .true., this will include normalized pressure (p)/poo in tecplot 
output. 

weight = .false. 

When .true., this will include a weight of one in tecplot output for use 
in setting up a near-body target pressure design. 
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B.4.36 fesboom 


This namelist contains variables that specify the inputs required to execute 
the sBOOM library. See section 9.2.7 for details. 


fesboom 

alt 

- 

45000.0 

h g 

= 

0.0 

headangle 

= 

0.0 

climbangle 

= 

0.0 

dmdt 

= 

0.0 

turnrate 

= 

0.0 

climbrate 

= 

0.0 

rs 

= 

500.0 

signum 

= 

10000 

zeronum 

= 

1200 

tol2 

= 

l.e-6 

nonlinear 

= 

1 

thermoviscous 

= 

1 

relaxation 

= 

1 

initialtimestep 

= 

0.01 

ref 1 

= 

1.9 

outf lag 

= 

0 

numouts 

= 

1000 

tol 

= 

0.005 

input ininches 

= 

0 

adjmode 

= 

1 

runmode 

= 

1 

objmode 

= 

1 

nazimuths 

= 

1 

phi ( : ) 

= 

0.0 

targetdbas ( : ) 

= 

56.0 

createtarget 

= 

0 

lowerbound 

= 

-1000.0 

upperbound 

= 

-1000.0 

lappass 

= 

500 

target_numpts ( : ) 

= 

0 

target_xx( : , : ) 

= 

0.0 

target_dpress ( : , 

:) = 

0.0 

tf lag 

= 

0 

ntalt 

= 

0 

ztalt ( : ) 

= 

0.0 

talt ( : ) 

= 

0.0 

windf lag 

= 

0 

nwindx 

= 

0 

zwindx( : ) 

= 

0.0 
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windx( : ) 

= 

0.0 

nwindy 

= 

0 

zwindy ( : ) 

= 

0.0 

windy ( : ) 

= 

0.0 

rf lag 

= 

0 

nhalt 

= 

0 

zrh( : ) 

= 

0.0 

rh( : ) 

= 

0.0 

bodylen 

= 

127.0 

reg 

= 

1 

CD 

T - 1 

regr 

= 

1 

CD 

T — 1 

lbd 

= 

0.99 

ubd 

= 

1.0 


alt = 45000.0 

This is the cruise altitude of the full-scale vehicle in feet. 
hg = 0.0 

This is the height of the ground in feet, 
headangle = 0.0 

This is the vehicle heading angle in degrees. A 180 heading would mean 
away from the x-axis, a 90 heading would mean away from the y- axis. 
This option is only relevant when winds are specified. 

climbangle = 0.0 

The is the vehicle climb angle in degrees. 

dmdt = 0.0 

This is the acceleration of the vehicle in 1/second (Mach number per 
second) . 

turnrate = 0.0 

This is the turning rate of the vehicle in degrees per second. 

climbrate = 0.0 

This is the climb rate of the vehicle in degrees per second. 

rs = 500.0 

This is the off-body distance in full-scale feet. This full-scale distance 
should match the location in grid units used to define y_ray and z_ray 
in &sonic_boom. 
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signum = 10000 

This is the number of points representing the off-body waveform for prop- 
agation. Increasing the number points reduces the discretization error 
of the Burgers equation and increase the execution time of sBOOM. 

zeronum = 1200 

This in the number of points used to zero pad the front part of the 
signature. These points are required to prevent the initial shock from 
propagating to the front of the Burgers equation domain and causing 
a numerical instability. The actual waveform will be sampled using 
(signum-zeronum) points. Typically, 10-20% of signum is required. 

tol2 = l.e-6 

This is the leading zero tolerance of the input waveform. It is used to 
truncate the initial portion of the off-body waveform before zero padding, 
where dp/p value are less than this number. 

nonlinear = 1 

This controls solution non-linearity, 

‘ 1 J uses cumulative non-linearity. 

‘ 0 J does not use cumulative non-linearity. 
thermoviscous = 1 

This controls the modeling of thermo-viscous absorption, 

‘ 1 ’ uses cumulative thermo-viscous absorption. 

‘ 0 J does not use thermo- viscous absorption. 

relaxation = 1 

This controls the modeling of molecular relaxation, 

‘ 1 ’ uses cumulative molecular relaxation. 

‘ 0 J does not use molecular relaxation. 

initialtimestep = 0.01 

Nondimensional initial step size for propagation. A smaller number pre- 
vents a multi-valued function, but increases execution time. If you re- 
ceive a discontinuity error, reduce this value. 

ref 1 = 1.9 

This is the ground reflection factor used to scale ground signatures. 

outflag = 0 

This determines the format of the output, 
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‘ 0 ’ outputs delta pressure in psf as a function of time in ms. 

‘ 1 J outputs delta pressure divided by freestream pressure as a function 
of x in feet. 

numouts = 1000 

This is the number of points requested in the ground signature. 
tol = 0.005 

This is the slope tolerance needed for removing zero paddings from the 
ground signatures. This allows signatures at different azimuthal angles 
to have the same time axis starting with the initial shock. 

inputininches = 0 

This is the units of the Fun 3D grid and geometry to scale the near field 
signature x for propagation, 

f 0’ for Fun 3D grid units in feet. 

‘ 1 ’ for Fun 3D grid units in inches. 

‘ 2 ’ for Fun 3D grid units in meters. 

ad j mode = 1 

This is the sBOOM simulation mode, 

‘ 1 J for a primal and adjoint simulation. 

‘ 0 J for primal simulation only. 

runmode = 1 

This is the type of propagation and the class of cost function, 

‘ 1’ propagates near field dp/p ^ to ground and adjoint sensitivities of 
ground based metrics defined by objmode. The target pressure is speci- 
fied with target_numpts, target.dpress, and target_xx. 

‘O’ reverse propagates near field dp/p^ to compute equivalent area 
(when rs< (alt— hg)) and directly converts off-body pressures to equiv- 
alent area (when rs> (alt— hg)). No ground signature or ground-based 
cost function is computed. See bodylen, reg, regr, lbd, and ubd. The 
target area distribution is specified with target_numpts, target.dpress, 
and targetvxx. 

objmode = 1 

This is the cost function definition. The value of runmode changes its 
behavior as follows, 
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‘ 1 ’ for an A-weighted loudness target of I = ( dBA — dBA t ) 2 when 
runmode=l and an equivalent area target / = Y^iLi ^[Ae(i) — Ae t arget(i)} 2 

when runmode=0. 

‘2’ for an inverse pressure design objective of I = Y^iLilP^) ~ p(M)] 2 
when runmode=l and an equivalent area sum / = JA =1 Ae(i) 2 when 

runmode=0. 

‘ 3 J for combined A-weighted loudness and inverse pressure design ob- 
jective of I = ( dBA — 56. 0) 2 + YliLi [p(*) — pit A)} 2 when runmode=l. 

‘4’ for an A-weighted loudness objective of I = dBA when runraode=l. 
nazimuths = 1 

This is the number of azimuths to propagate. The nazimuths must 
match nsignals in &sonic_boom. 

phi ( : ) = 0.0 

This is a nazimuths length vector of azimuthal locations in degrees, 
targetdbas ( : ) = 56.0 

This is the target (dBAt) at each azimuthal location when objmode=l. 
createtarget = 0 

This is the source of a ground target signature, 

‘ 0 J for no ground target signature. 

‘ 1 J to internally create a ground target by Laplace smoothing. The 
smoothing is controlled by lowerbound, upperbound, and lappass. 

‘ 2 J for a user specified target. The target is defined by the targetmumpts, 
target_xx, and target_dpress variables. 

lowerbound = -1000.0 

When createtarget=l, this is the lower bound in time (milliseconds) 
after which the user wants to Laplace smooth the computed signature 
to form the target. When runmode=0, this defines the start of locations 
in X (feet) where any difference in equivalent area between actual and 
target equivalent areas will contribute to the cost functional. Outside 
these bounds, even if the equivalent area does not match the target, it 
does not contribute to the cost functional. 

upperbound = -1000.0 

When createtarget=l, this is the upper bound in time (milliseconds) 
before which the user wants to Laplace smooth the computed signature 
to form the target. When runmode=0, this defines the end of locations 


259 



in X (feet) where any difference in equivalent area between actual and 
target equivalent areas will contribute to the cost functional. Outside 
these bounds, even if the equivalent area does not match the target, it 
does not contribute to the cost functional. 

lappass = 500 

The number of Laplace smoothing passes to generate a target ground 
signature. A higher number increases the smoothness of the target. It 
is only used for createtarget=l. 

target_numpts ( : ) = 0 

This is the number of points in the target_xx and target_dpress at 
each azimuth. It is used for runmode=l with objraode=2,3 or runmode=0 
with objmode=l. 

target _xx( ) = 0.0 

This is the time (in milliseconds) of the target signature at each azimuth 
for runmode =1 or x in feet for runmode=0. It is only used for some 
objective functions, see objmode. The first index is azimuthal location 
and the second index is the target signature point. 

target_dpress ( : , : ) = 0.0 

This is the delta pressure (in psf) of the target signature at each az- 
imuth for runmode=l or the equivalent area target for runmode=0. It is 
only used for some objective functions, see objmode. The first index is 
azimuthal location and the second index is the target signature point. 

tflag = 0 

This controls the source for the atmospheric temperature distribution, 
‘0 J for the 1976 U.S. Standard Atmosphere temperature profile. 

1 1 ’ for a temperature profile specified by ntalt, ztalt, and talt. 
ntalt = 0 

This is the number of ztalt altitude and talt temperature pairs to 
define the temperature profile. 

ztalt(:) = 0.0 

This is ntalt length vector of altitudes (in meters) to specify an atmo- 
spheric temperature distribution. 

talt(:) = 0.0 

This is ntalt length vector of temperature (in Fahrenheit) to specify an 
atmospheric temperature distribution. 
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windflag = 0 

This controls the source for winds, 

‘ 0 J for no winds. 

‘ 1 J for a wind prohle specified by nwindx, windx, zwindx, nwindy, 
windy, and zwindy. 

nwindx = 0 

This is the number of zwindx altitude and windx x-wind pairs that define 
the wind prohle. 

zwindx(:) = 0.0 

This is a vector of length nwindx of altitude (in meters) to specify a wind 
prohle. 

windx(:) = 0.0 

This is a vector of length nwindx of x-wind speeds (in meters/sec) to 
specify a wind prohle. 

nwindy = 0 

This is the number of zwindy altitude and windy y-wind pairs that define 
the wind prohle. 

zwindy(:) = 0.0 

This is a vector of length nwindy of altitude (in meters) to specify a wind 
prohle. 

windy(:) = 0.0 

This is a vector of length nwindy of y-wind speeds (in meters/sec) to 
specify a wind prohle. 

rflag = 0 

This controls the source for the atmospheric humidity distribution, 

‘0 J for the 1976 U.S. Standard Atmosphere relative humidity prohle. 

‘ 1 ’ for a relative humidity prohle specihed by nhalt, zrh, and rh. 
nhalt = 0 

This is the number of zrh altitude and rh relative humidity pairs. 
zrh(:) = 0.0 

This is a vector of length nhalt of altitude (in meters) to specify a 
relative humidity prohle. 
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rh( : ) = 0.0 


This is a vector of length nhalt of relative humidity (in percent) to 
specify a relative humidity profile. 

bodylen = 127.0 

This is the aircraft body length in feet. It is only used for the adjoint of 
equivalent area matching, runmode=0 and adjmode=l. 

reg = l.e-4 

This is the thermo- viscous absorption regularization parameter. A smaller 
value could lead to an ill-posed reverse diffusion problem. A higher value 
increases error. Applicable only when rs< (alt— hg). It is only used for 
equivalent area, runmode=0. 

regr = l.e-4 

This is the molecular relaxation regularization parameter. A smaller 
value could lead to an ill-posed reverse diffusion problem. A higher 
value increases error. Applicable only when rs< (alt— hg). It is only 
used for equivalent area, runmode=0. 

lbd = 0.99 

This is the under-deviation parameter for reversed equivalent area match- 
ing. Equivalent area deviations below a target are generally favorable to 
deviations above a target. Equivalent area matching cost functions and 
their sensitivities are only computed when the equivalent area is within 
the lbd and ubd limits. It is only used for the adjoint of equivalent area 
matching, runmode=0 and adjmode=l. 

ubd = 1.0 

This is the over-deviation parameter for reversed equivalent area match- 
ing. Equivalent area deviations below a target are generally favorable to 
deviations above a target. Equivalent area matching cost functions and 
their sensitivities are only computed when the equivalent area is within 
the lbd and ubd limits. It is only used for the adjoint of equivalent area 
matching, runmode=0 and adjmode=l. 
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B.4.37 &equi valent area 

This namelist contains variables that specify the inputs associated with equiv- 
alent area-based sonic boom cost functions, which is described in section 9.2.8. 
The number and order of these inputs should match the equivalent area (Ae) 
functions appearing in ../rubber. data. 

&equivalent_area 


nf unctions 

= 0 

nplane ( : ) 

= 0 

global_scaling_f actor ( : ) 

= 1.0 

lif t_scaling_f actor ( : ) 

= 1.0 

of f _track_angle ( : ) 

= 0.0 

nfunctions = 0 



This is the total number of Ae functions, including functions used as 
objectives and constraints. 

nplane(:) = 0 

This is the total number of cutting planes along x-axis for each Ae func- 
tion. 

global_scaling_f actor (: ) = 1.0 

This is the Ae(x) scaling factor for each Ae function. 

lif t_scaling_f actor (: ) = 1.0 

This is the Lift L(x) scaling factor for each Ae function, 
off _track_angle( : ) = 0.0 

This is the off-track angle in degrees for each Ae function. 
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B.4.38 &press box function 


This namelist contains variables that are required for the pressibox function, 
which is described in section 9.2.9. The namelist requires the ../rubber. data 
hie for the how and adjoint solvers. See section 6.3 for details on the min- 
imum inputs required for specifying the adjoint cost function. To compute 
the functional in the how solver, the --design_run command line option is 
required. 


&press_box_f unction 
integrand_type = 
gid 

xmin = 

xmax = 

ymin = 

ymax = 

zmin = 

zmax = 


0 

1 

-huge(l .0) 
huge (1 . 0) 
-huge(l .0) 
huge (1 . 0) 
-huge(l .0) 
huge (1 . 0) 


/ 


integrand.type = 0 

This integer indicates the functional form. 

‘ 0 J is the volume integral of pressure squared inside the defined box. 

‘ 1 J is the volume integral of ru-momentum inside the defined box. 

‘ 2 J is the volume integral of ^-momentum inside the dehned box. 

‘ 3 ’ is the density at the global node with index gid. Not admissible for 
eqn.type = ’ incompressible J . 

‘ 4 J is the time derivative of pressure at the global node with index gid. 

‘ 5 J is the time derivative of density at the global node with index gid. 
Not admissible for eqn.type = 5 incompressible ’ . 

gid = 1 

This integer is a global grid point index to be used with integrand.type 
= 3-5. 

xmin = -huge (1.0) 

This real value defines the lower bound in the x-direction for the box 
that encloses the volume integral. 

xmax = huge (1.0) 

This real value defines the upper bound in the x-direction for the box 
that encloses the volume integral. 
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ymin = -huge (1.0) 

This real value defines the lower bound in the y-direction for the box 
that encloses the volume integral. 

ymax = huge (1.0) 

This real value defines the upper bound in the y-direction for the box 
that encloses the volume integral. 

zinin = -huge (1.0) 

This real value defines the lower bound in the z-direction for the box 
that encloses the volume integral. 

zmax = huge(l.O) 

This real value defines the upper bound in the z-direction for the box 
that encloses the volume integral. 
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B.4.39 &pstag function 


This namelist contains variables that are required for the pstag function, 
which is described in section 9.2.5. This namelist requires the ../rubber. data 
hie for the flow and adjoint solvers. See section 6.3 for details on the min- 
imum inputs required for specifying the adjoint cost function. To compute 
the functional in the flow solver, the --desigmrun command line option is 
required. 


&pstag_f unction 

slice_orientation = 1 

disk_radius = 1.0 

x_disk_origin = 0.0 

y_disk_origin = 0.0 

z_disk_origin = 0.0 

/ 

slice_orientation = 1 


This integer represents the orientation of the cutting plane. The accept- 
able values are 1 (x-plane), 2 (y-plane), and 3 (z-plane). 

disk_radius = 1.0 

This real value is the radius of the disk over which the function is to be 
evaluated. 

x_disk_origin = 0.0 

This real value is the x-coordinate of the origin of the disk. 
y_disk_origin = 0.0 

This real value is the y-coordinate of the origin of the disk. 
z_disk_origin = 0.0 

This real value is the z-coordinate of the origin of the disk. 
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B.4.40 Especial parameters 

This namelist specifies changes to the discretization to handle elements with 
large face angles. 

&special_parameters 
large_angle_f ix 
override_bc_l imitation 
distance_chunk_size 

/ 

large_angle_f ix = 'off’ 

Grids with with elements that have adjacent face angles that approach 
180 degrees may result in a sudden onset of not a number (NaN). Grids 
produced by VGRID may contain these elements. 

'off’ uses all elements in viscous flux evaluation. This is a consistent 
viscous discretization. 

‘ on’ neglects viscous fluxes in cells containing angles between adjacent 
faces of 178 degrees or greater. This is an inconsistent discretization, 
but may allow the calculation of a solution on a grid that is not suitable 
for the consistent viscous discretization. 

override_bc_limitation = .false. 

Allow sensitivity analysis for cases with element-based boundary condi- 
tions. Users should contact Fun3D-Support@lists.nasa.gov to deter- 
mine if this option can be used for their simulation. 

distance_chunk_size = 20000000 

Size of the buffer surface boundary for use in the minimum distance 
determination required for turbulence models. 


= 'off' 

= .false. 

= 20000000 
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B.4.41 ^partitioning 


This namelist controls options related to the domain decomposition required 
for parallel execution. The load balancing of each partition execution time can 
be adjusted with the relative weighting (and cost model) controls to improve 
parallel scaling. 


.^partitioning 
partitioner 
lb_method 
topology 
partition_lines 
metis_numbering_entry 
use_64bit_partitioning 
imbalance_tol 
edge_weighting 
imesh_weighting 
e 1 ement _we ight ing 
tet_cost 
pyr_cost 
prz_cost 
hex_cost 

/ 


'parmetis ' 
' graph ' 

I I 


. false . 
17 

. false . 


1.01 

1 

1 

0 

10 

68 

75 

138 


partitioner = ’parmetis’ 

This determines which partitioning package to use. FUN3D must be 
built against the corresponding external library to enable an option. 

The available tools are, 

'parmetis’ is the ParMETlS partitioning tool, see section A. 7. 2 for 
installation details. 

'metis’ is the METIS partitioning tool distributed with ParMETlS, 
see section A. 7.2 for installation details. METIS can provide improved 
load balancing versus ParMETlS; however, serial METIS execution can 
increase memory requirements on the master node and grid processing 
time. See the related metis_numbering_entry variable description. 

' zoltan’ is the Zoltan partitioning tool, see section A. 7.3 for installation 
details. 

lb_method = ’graph’ 

This is the Zoltan load-balancing algorithm, requires partitioned ’ zoltan’ . 
' graph ’ graph partitioning. 

' hypergraph ’ hypergraph partitioning. It is not valid for twod_mode = 
.true.. 
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‘hier’ hierarchical graph partitioning for multicore architectures. This 
option requires topology to be defined. 

topology = ’ 5 

From the Zoltan documentation: “This comma-separated list of integers 
describes the topology of the multicore node. For example: ’ 2 , 8 ’ may 
refer to a dual-socket processor where the socket has 8 cores. ’ 2 , 4 , 6 ’ 
may refer to a dual-socket, 4-die, 6-core node. ’16’ would refer to a 
16-core node. Zoltan assumes each node (processor) of the multicore 
machine has the same architecture, and that the MPI process ranks are 
consecutive on the multicore nodes. In particular, if your parameters im- 
ply there are 4 MPI processes on each multicore node, Zoltan will assume 
that processes 0, 1, 2, and 3 are on the same node. Your system admin- 
istrator should be able to show you how to ensure that your processes 
are loaded in this order.” This string has no default value, only applies 
when partitioned’ zoltan’ , and must be set if lbunethod=’hier’ . 

partition.lines = .false. 

When .true., this option accounts for implicit lines during partitioning 
to minimize intersections of lines with partition boundaries. See sec- 
tion 4.4 for more details on implicit lines and how they are specified. 
Only relevant when partitioned ’ parmetis ’ . 

metis_numbering_entry = 17 

When partitioned ’ metis ’ , this integer indicates the location in the 
METIS_0PTI0N_NUMBERING metis. h header hie enumerated type entry used 
for the ‘options’ array. The C enumerated type is 0-based. This value is 
dependent on the METIS version being used; the default is appropriate 
for the METIS library that is bundled with ParMETIS v4.0.3. 

use_64bit_partitioning = .false. 

When .true., this option specifies 64-bit arguments to the ParMETIS in- 
terface. The default is 32-bit arguments. Only valid when partitioned 
’ parmetis ’ . 

imbalance_tol = 1.01 

This specifies the maximum acceptable load imbalance. For example, 1 
percent imbalance or less is requested with imbalance.tol = 1.01. 

edge .weighting = 1 

This weight expresses the relative importance of the number of adjacent 
edges to a vertex on the cost of that vertex. It is a relative quantity as 
compared to element .weighting and imesh.weighting. Any of these 
three weights can be zero to deactivate that style of weighting. The cost 
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of the nearest neighbor linear solution scheme of a vertex is proportional 
to the number of adjacent vertices (number of non-zeros in a matrix 
row). 

imesh_weighting = 1 

This is the relative importance of component grid (imesh) weighting for 
a composite overset grid system as compared to the other partitioning 
weights, element.weighting and edge_weighting. Any of these three 
weights can be zero to deactivate that style of weighting. This weight 
is ignored unless dynamic overset grids are utilized in the simulation. 
The intent is to load-balance the elasticity solver across the component 
meshes, which solves linear elasticity equations to determine volume grid 
deformation. 

element_weighting = 0 

This weight expresses the relative importance of the number of adjacent 
elements to a vertex on the cost of that vertex. It is a relative quantity as 
compared to edge_weighting and imesh_weighting. Any of these three 
weights can be zero to deactivate that style of weighting. The vertex cost 
of forming the viscous residual and linearization for the mixed-element 
implicit scheme scales with the number and relative cost of adjacent 
elements. A model for the relative cost of element types is constructed 
with tet_cost, pyr_cost, prz_cost, and hex_cost. 

tet_cost = 10 

This is the relative expense of computing fluxes and jacobians on tetra- 
hedral elements that is used to construct an element.weighting cost 
model. The cost is a relative measure as compared to pyr.cost, prz_cost, 
and hex_cost. 
pyr_cost = 68 

This is the relative expense of computing fluxes and jacobians on pyramid 
elements that is used to construct an element_weighting cost model. 
The cost is a relative measure as compared to tet_cost, prz.cost, and 
hex_cost. 

prz.cost = 75 

This is the relative expense of computing fluxes and jacobians on pris- 
matic elements that is used to construct an element_weighting cost 
model. The cost is a relative measure as compared to tet_cost, pyr_cost, 
and hex_cost. 

hex_cost = 138 

This is the relative expense of computing fluxes and jacobians on hex- 
ahedral elements that is used to construct an element_weighting cost 
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model. The cost is a relative measure as compared to tet_cost, pyr_cost, 
and prz_cost. 
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B.4.42 &fwh acoustic data 


This namelist controls the output of hies for interaction with Ffowcs Williams 
and Hawkings (FWH) [64] acoustic propagation packages such as PSU-WOPWOP 
[65] or AN0PP2 [66]. 

&fwh_acoustic_data 
fwh_data_f req 
append_to_prior_data 
output_initial_state 
n_fwh_bndry 
fwh_bndry_list 
geom_time_variation( : ) 
data_time_variation( : ) 
steps_per_period( : ) 
f ace_center_data 

/ 

fwh_data_f req = 0 

This is the iteration frequency of FWH output, where the special value 
-1 corresponds to once at the end of a successful run. This frequency 
applies to all FWH surfaces. 

append_to_prior_data = .true. 

When .true., this causes FWH data from the current run to be appended 
to existing FWH hies from previous runs. If .false, and there are exist- 
ing output hies for the surfaces in the current fwh_bndry_list, the data 
in those hies will be discarded and overwritten. This option applies to 
all FWH surfaces. 

output_initial_state = .false. 

When .true., this causes FWH data to be written for the initial state of 
the solution in the current run. This option is typically used for periodic 
cases so that if the solution is run for a multiple of the period, FWH 
data is written for both the starting and ending points of the period. 

n_fwh_bndry = 0 

This is the number of mesh boundaries for which FWH surface data 
will be written, and is the number of boundary patches to be specihed 
in fwhJbndrykList. When -1 is given, the number of mesh boundaries 
are inferred from fwhJbndryvlist. It can be helpful to set this number 
explicitly to ensure consistency with the variables geora_time_variation, 
geom_time_variation, and steps_per_period, where fwh_bndry_list 
is used to size their maximum dimension. 


= 0 

= . true . 

= .false. 

= 0 
_ I I 

= 'constant' 

= 'aperiodic' 
= 360 
= .false. 
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fwh_bndry_list = ’ ’ 

This is a list of boundary patch numbers for which FWH surface data 
will be written. Commas and dashes can be used to specify ranges, i.e., 
’ 1 , 2 , 5 - 7 ’. 

geom.time .variation! : ) = ’ constant ’ 

This categorizes the time variation of the geometry on which FWH data 
is output. The most common use case, where all FWH geometries have 
the same type of time variation, is facilitated by setting the first entry in 
the array with a string that includes an _all suffix as described below. 
Its maximum dimension is set by fwh_bndry_list. 

' constant’ when this FWH surface geometry does not vary with time. 

'periodic’ when this FWH surface geometry is periodic in time 

'aperiodic’ when this FWH surface geometry varies with time, but it 
is not periodic in time. 

' constant.all ’ assigns ’constant’ to all FWH surface geometries, 
when geom.time .variat ion (1) = ’ constant_all’ . 

' periodic.all ’ assigns ’periodic’ to all FWH surface geometries, 
when geom.time .variat ion (1) = ’ periodic.all ’ . 

' aperiodic.all ’ assigns ’aperiodic’ to all FWH surface geometries, 
when geom.time .variat ion (1) = ’ aperiodic.all ’ . 

data.time .variation! : ) = ’aperiodic’ 

This categorizes the time variation of the FWH data (surface pressure) 
that is output. The most common use case, where all FWH data have 
the same type of time variation, is facilitated by setting the first entry in 
the array with a string that includes an .all suffix as described below. 
Its maximum dimension is set by fwh_bndry_list. 

' constant’ when this FWH surface data does not vary with time. 

'periodic’ when this FWH surface data is periodic in time 

'aperiodic’ when this FWH surface data varies with time, but it is 
not periodic in time. 

'constant.all’ assigns ’constant’ to all FWH surface data, when 
data_time_variation(l) = ’constant.all’. 

'periodic.all’ assigns ’periodic’ to all FWH surface data, when 
data_time_variation(l) = ’periodic.all’. 

'aperiodic.all’ assigns ’aperiodic’ to all FWH surface data, when 
data_time_variation(l) = ’aperiodic.all’. 
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steps_per_period( : ) = 360 

When geoimtime .variation = 'periodic’ or data.time.variation 
= ’periodic’, this indicates the number of time steps in one period. 
When both geom_time .variation and data_time_variation are set to 
’periodic’ for a particular surface, both geometry and data are as- 
sumed to have the same period. The most common use case, where all 
periodic FWH surfaces have the same period, is facilitated by setting 
the period of the first FWH surface to a negative value. For exam- 
ple, steps_per_period(l) = - (steps_per_period for all). Its max- 
imum dimension is also set by fwh_bndry_list. 

f ace_center_data = .false. 

When .true., this option provides data at face centers. When .false., 
the acoustic data is provided at surface grid nodes. Nodal output is 
the preferred, since it results in smaller hies and provides connectivity 
data that may be required by the FWH code. The option for data at 
face centers is provided for backwards compatibility with older processes. 
This option applies affects all output FWH surfaces. 
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B.4.43 &vortex generator 

This namelist is used to specify parameters related to source terms designed 
to simulate the effects of vortex generators. 

&vortex_generator 
number_of _vgs 
configuration ( : ) 
boundary_patchl ( : ) 
boundary _patch2 ( : ) 
planf orm_area( : ) 
height (: ) 

calibration_constant ( : ) 
pointl_xcoord( : ) 
pointl_ycoord( : ) 
pointl_zcoord( : ) 
point2_xcoord( : ) 
point2_ycoord( : ) 
point2_zcoord( : ) 
point3_xcoord( : ) 
point3_ycoord( : ) 
point3_zcoord( : ) 
reverse_t ( : ) 
reverse_n( : ) 

/ 

number _of_vgs = 0 
Specifies the number of user-defined vortex generators (max 1000). 

conf iguration( : ) = ’ area_and_height ’ 

Specifies the input configuration for each vortex generator. If config- 
uration^) is ’ area_and Jieight ' , then the ith vortex generator planform 
will be a symmetric trapezoid with the endpoints of its base defined by 
the point 1 and point2 coordinate inputs in the namelist and its area 
and height defined by the planform_area(i)and height(i) values. If con- 
figuration^) is 'three points’, then the ith vortex generator will have a 
triangular planform where the user must supply the coordinates of a 
third point defining the off-surface tip of the vortex generator geometry. 
In this case, the planform area and height are derived quantities based 
on the three input point locations. 

boundary.patchl ( : ) =0 

Specifies the boundary patch index for pointl of the ith vortex generator. 
This patch will be used for projection of the pointl coordinates specified. 


= 0 

= 1 area_and_height 1 
= 0 
= 0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= .false. 

= .false. 
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boundary_patch2 ( : ) = 0 

Specifies the boundary patch index for point2 of the ith vortex generator. 
This patch will be used for projection of the point2 coordinates specified. 

planf orm_area( : ) = 0.0 

Specifies the intended planform area of the ith vortex generator. This 
input only required if configuration = ’area_and_height’. 

height(:) = 0.0 

Specifies the height of the ith vortex generator. This input only required 
if configuration = ’area and height'. 

calibration_constant ( : ) = 0.0 

Specifies the calibration constant of the ith vortex generator. 

pointl_xcoord( : ) = 0.0 

Specifies the x-coordinate of point 1 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patchl(i). 

pointl_ycoord( : ) = 0.0 

Specifies the y-coordinate of point 1 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patchl(i). 

pointl_zcoord( : ) = 0.0 

Specifies the z-coordinate of point 1 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patchl(i). 

point2_xcoord( : ) = 0.0 

Specifies the x-coordinate of point 2 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary _patch2(i). 

point2_ycoord( : ) = 0.0 

Specifies the y-coordinate of point 2 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary _patch2(i). 

point2_zcoord( : ) = 0.0 

Specifies the z-coordinate of point 2 defining the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary _patch2(i). 
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point3_xcoord( : ) = 0.0 

Specifies the x-coordinate of point 3 defining the ith vortex generator 
location. This input only required if configuration = ’three points’. 

point3_ycoord( : ) = 0.0 

Specifies the y-coordinate of point 3 defining the ith vortex generator 
location. This input only required if configuration = ’three .points’. 

point3_zcoord( : ) = 0.0 

Specifies the z-coordinate of point 3 defining the ith vortex generator 
location. This input only required if configuration = ’three points’. 

reverse_t(:) = .false. 

Reverse the assumed direction of the unit vector t for the ith vortex 
generator. 

reverse_n(:) = .false. 

Reverse the assumed direction of the unit vector n for the ith vortex 
generator. 

Additional information on the use of vortex generator source terms 

The implementation of these source terms in Fun 3D is based on the heuristic 
model described in [67] and previous references cited therein. The approach 
avoids the need for resolving geometric details of vortex generator devices 
during mesh generation. Sufficient grid resolution may still be required to 
convect the simulated effects of the vortex generator downstream as desired. 
The user must also provide a calibration constant for each simulated vortex 
generator. This value should be chosen carefully to produce the desired impact 
on the local flowheld. Vortex generator source terms currently may only be 
applied to static grid simulations. The source terms are treated fully implicit 
during the solution procedure. 

After developing the desired set of namelist inputs, it is useful to run the 
solver for a single iteration, requesting boundary output for (at least) the 
boundaries on which vortex generators are to be placed. The geometry for 
each vortex generator as determined by Fun 3D based on the namelist inputs 
will be provided in the Tecplot M hie [project_rootnamej_vg_geometry.dat. 
The user should visualize the placement of each vortex generator in relation 
to the boundary patches of the grid to ensure the desired placement. 

The user will also be provided with a Tecplot™ hie [projectxrootname] 
_vg_vectors.dat. This hie contains the unit vectors b , t, and n according to 
the notation described in [67]. The user should visualize these vectors to ensure 
that they are oriented appropriately. The vector b is defined uniquely by the 
local boundary orientation; however, Fun 3D attempts to infer the directions 
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of the vectors t and n based on the freestream direction. If the local flow 
direction is expected to be substantially different, these vectors may need to 
be manually reversed using the appropriate namelist inputs. 

If desired, the user may also plot the points at which the actual source 
terms will be computed by ‘scatter plotting’ the data contained in the Tec- 
plot™ hie [project_rootnamel_vg_source_locations.dat. These locations 
are determined by the intersections of the vortex generator geometries with 
edges in the grid. Source terms are computed at each of these locations then 
scattered to the residual values at either end of the intersecting edge. 

An example of the geometry features described above and the local howheld 
in the vicinity of simulated trapezoidal and triangular vortex generators near 
the leading edge of a wing is shown here. 




r ho 



Unit vector n 


Figure B4: View of trapezoidal and triangular vortex generators placed near 
the leading edge of a wing geometry. The unit vectors b, t, and n are shown, 
as well as the points where the actual source terms will be computed. 
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B.5 moving body. input 


This namelist file is only used for time-dependent, moving grid cases to specify 
grid motion as a function of time. This file must be used in conjunction 
with input variable moving_grid = .true, in the feglobal namelist of the 
fun3d.nral input file. See section 7 for an overview of moving grid capabilities. 

The grid-motion options in Fun 3D are fairly generally in order to handle 
a wide variety of applications. The basic approach is for the user to define one 
or more boundaries in the grid to be a ‘body’. Multiple bodies may be de- 
fined. Basic setup for these bodies is established using the febody .definitions 
namelist. A hierarchical relation may be established between multiple bodies 
to allow the motion of one body (a ‘child’) to follow the motion of another 
body (the ‘parent’). The top level of this hierarchy is the inertial reference 
frame, and all motion is ultimately referenced back to this inertial frame. Each 
body has its own reference frame, and the reference frames of all bodies are 
assumed to be coincident with the inertial reference frame at t=0. 

Having established the basic body definition(s), the user specifies a general 
descriptor (motion.driver) for the mechanism that will drive the motion of 
the body, and specifies how the mesh is to be moved - by rigid motion or 
by deformation (or both) - in response to the body motion. Note that mesh 
deformation requires more CPU time than rigid mesh motion, and is less ro- 
bust. Mesh deformation may lead to negative cell volumes, at which point the 
solution is terminated, while rigid motion will preserve positive cell volumes. 
Thus, rigid mesh motion should be favored over mesh deformation whenever 
possible. However, there are certain situations where only a deforming mesh 
is appropriate. For example if the body is aeroelastic, then the mesh must be 
deformed to fit the deformed body surface. In some situations the potential 
for a deforming mesh to encounter negative cell volumes can be mitigated by 
combining deformation with rigid motion. An example of this is the motion 
of elastic rotor blades, wherein the overall rotational motion of the blades is 
handled via rigid rotation, but the relatively smaller elastic deflection of the 
blades is handled via deformation. 

The motion.driver specification simply provides a notional mechanism for 
how the body is to be moved; details of this mechanism are then provided by 
one or more additional namelists. For example, if motion.driver = ‘forced’ 
then details of how to move the body, perhaps by rotation with a given fre- 
quency and amplitude, are specified via the &f orced_motion namelist. Other 
options for motion.driver - and the required auxiliary namelists to specify 
the details - are given in the following sections. 

By default, boundary output from Fun 3D for visualization purposes (see 
section 5.3.1) is provided in the inertial frame. It is sometimes useful to have 
this output in a different reference frame, an ‘observer’ frame. For example, 
the observer frame might be one attached to a moving body. Specification of 
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an alternate observer frame is handled via the feobserver anotion namelist. 
See the following sections for descriptions of the namelists in this file. 
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B.5.1 &body definitions 

This namelist specifies which mesh surfaces define the moving bodies. In 
general, each body may have a different motion. However, there are some 
fundamental constraints. For example, in a mesh with multiple bodies under- 
going different motions, either overset meshes or a deforming mesh would be 
required. Note that a deforming mesh might well support only small relative 
motions between the bodies before the mesh becomes invalid (negative cell 
volumes). For a single rigid mesh, all bodies within the mesh would need to 
have the same motion. 

&body_def initions 


n_moving_bodies 

= 

0 

body_frame_f orces 

= 

.false . 

output_transf orm 

= 

.false . 

dimens ional_output 

= 

.false . 

ref .velocity 

= 

1117.0 

ref .density 

= 

0.002378 

ref .length 

= 

1.0 

body .name ( : ) 

= 

1 1 

parent.name ( : ) 

= 

1 1 

n.def ining.bndry ( : ) 

= 

0 

def ining.bndry ( : , : ) 

= 

0 

motion.driver ( : ) 

= 

' none ' 

mesh.movement ( : ) 

= 

' static ' 

x.mc ( : ) 

= 

xmc 

y.mc ( : ) 

= 

ymc 

z.mc ( : ) 

= 

zmc 

s.ref ( : ) 

= 

sref 

c.ref ( : ) 

= 

cref 

b.ref ( : ) 

= 

bref 

move_mc( : ) 

= 

1 

trim.control ( : ) 

= 

' none ' 

baseline.psi ( : ) 

= 

0.0 

steps_per_period( : ) 

= 

0 


/ 

n_moving_bodies = 0 


This is the number of bodies in motion. 
body_frame_f orces = .false. 

This outputs aero forces acting on the body in the frame of the body 
when .true., rather than in the inertial reference frame. 

output .transform = .false. 

This outputs the transform matrix to Transf ormMatrixBody_N.hst for 
body N when .true.. 
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dimensional.output = .false. 


This outputs the body state data (displacements, velocities, and aero 
forces) in dimensional form for forced or 6-DOF motions. Use with 
ref ^velocity, ref_density, and ref_length to produce body state 
output with the desired units. 

refwelocity = 1117.0 

This is the reference velocity to make aerodynamic forces dimensional, 
when dimensional_output = .true. Note that this should correspond 
to the sound speed if compressible. The default corresponds to standard 
sea level speed of sound, in ft/sec. 

ref_density = 0.002378 

This is the reference density to make aerodynamic forces dimensional, 
when dimensional.output = .true. The default corresponds to stan- 
dard sea level density, in slugs/ft 3 . 

ref_length = 1.0 

This is the reference length to make aerodynamic forces dimensional, 
when dimensional_output = .true. The default corresponds to one 
unit consistent with the values of ref.velocity and ref.density (i.e. , 
1 ft for the default reference conditions). 

body_name ( : ) = ’ ’ 

This is the name used to identify the body; the array index corresponds 
to body number. 

parent_name( : ) = ’’ 

This is the name of the parent body; the array index corresponds to body 
number. The motion of a body follows (i.e., is added to) the motion of 
the parent. When naming the parent, ’ ’ signifies that the parent is the 
inertial frame. For single or independently-moving bodies, the default 
parent _name should be used. 

n_def ining_bndry ( : ) = 0 

This is the number of boundaries that define the body; the array index 
corresponds to body number. 

def ining.bndry ( : , : ) = 0 

This is a list of n_def iningJbndry boundaries that define the body; the 
array index 1 corresponds to the boundary (from 1 to n_def iningJbndry) 
defining the body; the array index 2 corresponds to the body number. 
If boundary lumping is used (section B.4.2), the boundaries must corre- 
spond to lumped boundaries. 


282 


motion.driver ( : ) = ’none’ 

This is the body motion mechanism; the array index corresponds to body 
number: 

' none ’ is for no motion. 

'forced’ uses forced motion prescribed in &f orcedanotion. 

' surf ace_f ile ’ uses surface motion prescribed in &surf aceanotion_f rom_f ile. 

' motion_f ile ’ uses motion prescribed in &motion_from_f ile. 

' 6dof ’ computes motion via 6-DOF library, which is governed by &sixdof anotion. 

' aeroelastic ’ computes motion via &aeroelastic_modal_data, or by 
coupling with an external FEM. 

'custom’ uses custom_kinematics; the user supplies a custom trans- 
form matrix as a function of time and design variables. 

meshanovement ( : ) = ’static’ 

This is the type of grid movement associated with body motion; the 
array index corresponds to body number: 

'static’ no mesh movement. 

' rigid’ rigid mesh movement; all nodes of the mesh rotate/translate in 
unison with the body. 

'deform’ deforms the mesh locally to accommodate the motion of the 
solid body. 

' rigid+def orm’ mesh undergoes both rigid and deforming motions 
xanc ( : ) = xmc 

The is the ^-coordinate of moment center at t — 0; the array index 
corresponds to body number. 

y _mc ( : ) = ymc 

This is the y-coordinate of moment center at t — 0; the array index 
corresponds to body number. 

zanc(:) = zmc 

This is the ^-coordinate of moment center at t — 0; the array index 
corresponds to body number. 

s_ref(:) = sref 

This is the nondimensional reference area for force and moment normal- 
ization; the array index corresponds to body number. 
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c_ref(:) = cref 

This is the nondimensional reference chord length for force and moment 
normalization; the array index corresponds to body number. 

b_ref ( : ) = bref 

This is the nondimensional reference span length for force and moment 
normalization; the array index corresponds to body number. 

movennc(:) = 1 

This controls the movement of the moment center; the array index cor- 
responds to body number. 

‘ 0 ’ leave moment center fixed in space 

‘ 1 : ’ move moment center following the body number indicated by the 
value of move_mc (body) (applicable only for rigid-body motion of body 
movennc(body)) 

trim_control ( : ) = ’none’ 

This controls whether trim as applied to the body; the array index cor- 
responds to body number. 

‘ none ’ no trim control applied; 

‘ design J trim control applied via design variables; 

‘ bodyjnotion J trim control applied via moving body components; 

baseline.psi ( : ) = 0.0 

This is the starting azimuth for trim when trim is used as a design 
variable; the array index corresponds to body number. 

steps_per_period( : ) = 0 

This is the number of steps to define a trim period when trim is used as 
a design variable; the array index corresponds to body number. 
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B.5.2 ^forced motion 


&f orced_motion 


rotate ( : ) 

- 

0 

rotation_rate ( : ) 

= 

0.0 

rotation_f req( : ) 

= 

0.0 

rotation_phase ( : ) 

= 

0.0 

rotation_tphase ( : ) 

= 

0.0 

rotation_amplitude ( : ) 

= 

0.0 

rotation_origin_x( : ) 

= 

0.0 

rotation_origin_y ( : ) 

= 

0.0 

rotation_origin_z( : ) 

= 

0.0 

rotation_vector_x( : ) 

= 

0.0 

rotation_vector_y ( : ) 

= 

1.0 

rotation_vector_z( : ) 

= 

0.0 

rotation_start ( : ) 

= 

0.0 

rotation_duration( : ) 

= 

1 . 0e99 

translate ( : ) 

= 

0 

translation_rate ( : ) 

= 

0.0 

translation_f req( : ) 

= 

0.0 

translation_phase ( : ) 

= 

0.0 

translation_tphase ( : ) 

= 

0.0 

translation_amplitude ( : ) 

= 

0.0 

translation_vector_x( : ) 

= 

0.0 

translation_vector_y ( : ) 

= 

0.0 

translation_vector_z( : ) 

= 

1.0 

translation_start ( : ) 

= 

0.0 

translation_duration( : ) 

= 

1 . 0e99 


rotate(:) = 0 

This is the type of rotational motion; the array index corresponds to 
body number: 

‘ : - 1 ’ rotate to match Cl target 
‘ 0 J for no rotation. 

‘ 1 ’ for constant rotation rate, rotationxrate. 

‘ 2 J is sinusoidal rotation where 6 = rotation.amplitude sin(27r rotation_f req t + 

rotation.phase 7r/ 180) + rotation_tphase 7t/ 180 and t is nondimen- 

sional. 

‘ 3 ’ is a square-wave doublet in rotation 6 = rotation.amplitude for the 
first half of the specified rotation.duration and 6 = -rotation.amplitude 
for the second half of the specified rotation.duration 
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rotation_rate( : ) = 0.0 


This is the nondimensional rotation rate associated with rotate=l; the 
array index corresponds to body number. For eqmtype = ’ compressible ’ , 
the nondimensional rate is to = to*— — rj r — , where u* is the dimen- 

a ref^ref 

sional rotation rate, in rad/sec. For eqmtype = 'incompressible’, 
the nondimensional rate is to = — r -¥- — ; see also section 2. 

rotatiomf req( : ) = 0.0 

This is the nondimensional rotation reduced frequency associated with 
rotate=2; the array index corresponds to body number. For eqmtype 

Li* 

= ’compressible’, the nondimensional frequency is / = /*— — — , 

where /* is the dimensional frequency, in Hertz (cycles/sec). For eqmtype 

L* 

= ’ incompressible’ , the nondimensional frequency is / = f*T?z — — ; 

v ref^ref 

see also section 2. 

rotatiomphase ( : ) = 0.0 

This is the rotation phase shift (in degrees) associated with rotate=2; 
the array index corresponds to body number. 

rotatiomtphase ( : ) = 0.0 

This is the rotation offset (in degrees) associated with rotate=2 or 3; 
the array index corresponds to body number. 

rotatiomamplitude ( : ) = 0.0 

This is the rotation amplitude (in degrees) associated with rotate=2 or 
3; the array index corresponds to body number. 

rotation_origin_x( : ) = 0.0 

This is the x-coordinate of rotation center; the array index corresponds 
to body number. 

rotatiomorigimy ( : ) = 0.0 

This is the ^-coordinate of rotation center; the array index corresponds 
to body number. 

rotatiomorigimz( : ) = 0.0 

This is the ^-coordinate of rotation center; the array index corresponds 
to body number. 

rotation_vector_x( : ) = 0.0 

This is the x-component of a unit vector along the rotation axis; the 
array index corresponds to body number. 


286 


rotation_vector_y ( : ) = 1.0 


This is the ^/-component of a unit vector along the rotation axis; the 
array index corresponds to body number. 

rotation_vector_z( : ) = 0.0 

This is the z-component of a unit vector along the rotation axis; the 
array index corresponds to body number. 

rotation_start ( : ) = 0.0 

This is the nondimensional time at which the rotational motion begins 
the array index corresponds to body number. 

rotation_duration( : ) = 1.0e99 

This is the nondimensional time over which the rotational motion is 
active; the array index corresponds to body number. After this time the 
rotational motion is zeroed out. 

translated ) = 0 

This is the type of translational motion; the array index corresponds to 
body number: 

‘ 0 J for no translation. 

‘ 1 ’ for a constant translation rate, translation_rate. 

‘ 2 J is sinusoidal translation where displacement = translation.amplitude 

sin(27r translation_freq t + translation.phase 7 t/ 180) + translation.tphase 7r/ 180 

and t is nondimensional. 

translation_rate( : ) = 0.0 

This is the nondimensional translation rate associated with translate= 

1; the array index corresponds to body number. For eqn.type = ’ compressible ’ , 
the nondimensional translation rate is V — V*/a* re f, where V* is the 
dimensional translation rate (for example, in ft/sec). For eqn.type = 

’ incompressible ’ , the nondimensional translation rate is V = V*/V* re f] 
see also section 2. 


translation^ req( : ) = 0.0 


L* r 


This is the nondimensional translation reduced frequency associated 
with translate=2; the array index corresponds to body number. For 
eqn.type = J compressible ’ , the nondimensional frequency is f = f* 
where /* is the dimensional frequency, in Hertz (cycles/sec). For eqnrtype 
= ’ incompressible ’ , the nondimensional frequency is / = /* ^ — ; 
see also section 2. 




ref^ref 
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translation.phase ( : ) = 0.0 

This is the translation phase shift (in degrees) associated with translate= 
2; the array index corresponds to body number. 

translation_tphase ( : ) = 0.0 

This is the translation offset (in grid units) associated with translate=2; 
the array index corresponds to body number. 

translation.amplitude ( : ) = 0.0 

This is the translation amplitude (in grid units) associated with translate 
2; the array index corresponds to body number. 

translation_vector_x( : ) = 0.0 

This is the ^-component of a unit vector along the translation axis; the 
array index corresponds to body number. 

translation_vector_y ( : ) = 0.0 

This is the ^/-component of a unit vector along the translation axis; the 
array index corresponds to body number. 

translation_vector_z( : ) = 1.0 

This is the ^-component of a unit vector along the translation axis; the 
array index corresponds to body number. 

translation_start ( : ) = 0.0 

This is the nondimensional start time of the translational motion; the 
array index corresponds to body number. 

translation_duration( : ) = 1.0e99 

This is the nondimensional duration of the translational motion; the 
array index corresponds to body number. 
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B.5.3 &:observer motion 


This namelist specifies motion of an observer as a function of time for boundary 
animation purposes (see the &boundary_output_variables namelist for more 
details); the animation is output from the point of view of the observer. 


&observer_motion 

ob_parent_name = ' ' 

ob_rotate = 0 

ob_rotation_rate = 0.0 

ob_rotation_f req = 0.0 

ob_rotation_phase = 0.0 

ob_rotation_tphase = 0.0 

ob_rotation_amplitude = 0.0 
ob_rotation_origin_x = 0.0 
ob_rotation_origin_y = 0.0 
ob_rotation_origin_z = 0.0 
ob_rotation_vector_x = 0.0 
ob_rotation_vector_y = 1.0 
ob_rotation_vector_z = 0.0 
ob_translate = 0 

ob_translation_rate = 0.0 

ob_translation_f req = 0.0 

ob_translation_phase = 0.0 
ob_translation_tphase = 0.0 
ob_translation_amplitude = 0.0 
ob_translation_vector_x = 0.0 
ob_translation_vector_y = 0.0 
ob_translation_vector_z = 1.0 

/ 


ob_parent_name = J ’ 

This is the observer parent reference frame. The default indicates the 
inertial reference frame - the same as when observer motion is not ex- 
plicitly specified. 

ob_rotate = 0 

This is the type of rotational motion: 

‘ 0 J for no rotation. 

‘ 1 ’ for a constant rotation rate, ob_rotation_rate. 

‘ 2 J is sinusoidal rotation where 6 = ob_rotation_amplitude sin(27r ob_rotation_f req t + 
ob_rotation_phase 7r/ 180) and t is nondimensional. 
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ob_rotation_rate = 0.0 


This is the nondimensional rotation rate associated with rotate=l. For 

L ref 


ef^ref ' 


eqnvtype = 5 compressible ’ , the nondimensional rate is oj = u* 
where iv* is the dimensional rotation rate, in rad/sec. For eqn.type = 
’ incompressible J , the nondimensional rate is u = u * — ; see also 
section 2. 

ob_rotation_f req = 0.0 


This is the nondimensional rotation reduced frequency associated with 
rotate=2. 

ob_rotation_phase = 0.0 

This is the rotation phase shift (in degrees) associated with rotate=2. 


ob_rotation_tphase = 0.0 

This is the rotation phase shift (in degrees) applied to transform matrix. 


ob_rotation_amplitude = 0.0 

This is the rotation amplitude (in degrees) associated with rotate=2. 


ob_rotation_origin_x = 0.0 

This is the ^-coordinate of rotation center. 

ob_rotation_origin_y = 0.0 

This is the //-coordinate of rotation center. 

ob_rotation_origin_z = 0.0 

This is the z-coordinate of rotation center. 

ob_rotation_vector_x = 0.0 


This is the ^-component of a unit vector along the rotation axis. 

ob_rotation_vector_y = 1.0 

This is the //-component of a unit vector along the rotation axis. 
ob_rotation_vector_z = 0.0 

This is the z-component of a unit vector along the rotation axis. 

ob_translate = 0 

This is the type of translational motion: 

‘ 0 J for no translation 

'1* for constant translation rate, ob_translate_rate. 

‘ 2 J is sinusoidal translation where displacement = ob_translation_amplitude 
sin(27T ob_translation_freq t + ob_translation_phase pf/180) arid t 
is nondimensional. 
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ob_translation_rate = 0.0 


This is the nondimensional translation rate associated with translate= 

1. For eqnrtype = ’ compressible ’ , the nondimensional translation 
rate is V = V*/a* re f, where V* is the dimensional translation rate (for 
example, in ft/sec). For eqn.type = ’ incompressible ’ , the nondimen- 
sional translation rate is V = V* /V* re f] see also section 2. 

ob_translation_freq = 0.0 

This is the nondimensional translation reduced frequency associated with 
translate=2. For eqnrtype = ’compressible’, the nondimensional 
frequency is / = f* t L re / — , where f* is the dimensional frequency, in 
Hertz (cycles/sec). For eqnrtype = ’ incompressible ’, the nondimen- 
sional frequency is / = f*T 7 i — r ~¥ — ; see also section 2. 

ob_translation_phase = 0.0 

This is the translation phase shift (in degrees) associated with translate= 

2 . 

ob_translation_tphase = 0.0 

This is the translation phase shift (in degrees) applied to transform ma- 
trix. 

ob_translation_amplitude = 0.0 

This is the translation amplitude (in grid units) associated with translate 
2 . 

ob_translation_vector_x = 0.0 

This is the x-component of a unit vector along the translation axis. 
ob_translation_vector_y = 0.0 

This is the ^-component of a unit vector along the translation axis. 

ob_translation_vector_z = 1.0 

This is the r-component of a unit vector along the translation axis. 
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B.5.4 Emotion from file 

This namelist specifies rigid body (and grid) motion via a file containing a 4x4 
transform matrix as a function of time. It allows user-defined motion that is 
more general than the motions available in the &f orcedunotion namelist. 


&motion_f rom_f ile 

n_time_slices_f ile ( : ) 
repeat_time_f ile ( : ) 
motion_f ile ( : ) 
motion_f ile_type( : ) 

/ 


= 0 

= 1.0e+99 

_ I I 

= ' transf orm_matrix ' 


n_time_slices_f ile( : ) = 0 

This is the number of transforms (at selected points in time) defining 
the motion of the body; the array index corresponds to body number. 
All the transforms for a particular body are contained in a single file. 


repeat_time_f ile( : ) = 1.0e+99 

This is the nondimensional time when the motion will repeat; the array 
index corresponds to body number. 


motion_f ile( : ) = ; ’ 

This is the name of the ASCII file that contains the transform matrices 
used to set the grid position and orientation of the body for each of the 
specified instants in time; the array index corresponds to body number. 
The following pseudo code illustrates how such a motion file might be 
created: 

loop over time steps 
writeQ simulationrtime 
write () xcg, ycg, zcg 
do i=l,4 

write () transf orm_matrix(i , j ) , j=l,4) 
end do 

end time step loop 

where simulation.time is the nondimensional time, and where xcg, ycg, zcg 
are the coordinates of the center of gravity of the body in grid units. 


motion_f ile_type( : ) = ’ transf orIn_matrix , 

This is the type of transform matrix specified; the array index corre- 
sponds to body number: 

‘ transf orm_matrix ; specifies the transform from inertial coordinates 
to body (moving) coordinates as a matrix. 
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‘ inversevtransf orm’ specifies the transform from body (moving) co- 
ordinates to inertial coordinates as a matrix. 
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B.5.5 ^surface motion from file 

This namelist allows the motion of surface grids to be defined in files. Since 
only the surface is specified, meshjiiovement = ’deform’ must be used to 
deform the volume mesh to conform to the specified surface. These files must 
be named [project_rootnamel_bodyI\LtimestepM.dat, where N is the body 
number and M is the time slice index (1 to n_time_slices). The files are ASCII 
Tecplot files with a zone title line that contains “TIME simulationvtime” , 
where simulationvtime is nondimensional time. The variables in the file are 
the values of x, y, z, as well as id, where id is the global grid number of the 
surface point. 

&surf ace_motion_f rom_f ile 
n_time_slices ( : ) = 0 
repeat_time ( : ) = 1.0e+99 

/ 

n_time_slices ( : ) = 0 

This is the number of equally spaced instants in time (and files describing 
the shape at those times) defining the motion of the body; the array index 
corresponds to body number. Each file contains the surface shape at a 
point in time. 

repeatvtime ( : ) = 1.0e+99 

This is the nondimensional time when the motion will repeat; the array 
index corresponds to body number. 
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B.5.6 &sixdof motion 


This namelist provides details of 6-DOF motion simulations. It requires link- 
ing to the 6-DOF library, see section A. 7.6. NOTE: most data in this namelist 
is input as dimensional data. For 6-DOF motion, the variables ref .velocity, 
ref.density and ref.length in the namelist febody .definitions must also 
be set, in units consistent with those used in fesixdof .motion. Note (impor- 
tant): data are assumed to be in FUN3D body coordinates, which are the 
FUN3D coordinates at t=0. Note that the assumption of FUN3D coordinates 
applies to the moments of inertia. 


fesixdof .motion 
mass ( : ) 
cg_x( : ) 
cg_y(:) 
cg_z( : ) 
i_xx( : ) 

i_yy(:) 

i_zz( : ) 
i_xy ( : ) 
i_xz( : ) 
i_yz( : ) 

body_lin_vel ( : , : ) 
body_ang_vel ( : , : ) 
euler_ang( : , : ) 
gravity.dir (1 : 3) 
gravity.mag 
n.extf orce ( : ) 
n.extmoment ( : ) 
file.ext force ( : , : ) 
f ile.extmoment ( : , : ) 
ignore_x_aerof orce ( : ) 
ignore_y_aerof orce ( : ) 
ignore_z_aerof orce ( : ) 
ignore_x_aeromoment ( : ) 
ignore_y_aeromoment ( : ) 
ignore_z_aeromoment ( : ) 
print _sixdof .summary 
use. spec if ied_aero.dat a 
use.restart.mass.properties 


1.0 

0.0 

0.0 

0.0 

1.0 

1.0 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0 . 0 , 0 . 0 , - 1.0 

32.2 

0 

0 
I I 

I I 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 


mass(:) = 1.0 

This is the mass of the body; the array index corresponds to the body 
number. 
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cg_x ( : ) = 0.0 

This is the ^-coordinate of the center of gravity; the array index corre- 
sponds to the body number. 

cg_y(:) = 0.0 

This is the ^/-coordinate of the center of gravity; the array index corre- 
sponds to the body number. 

cg_z ( : ) = 0.0 

This is the ^-coordinate of the center of gravity; the array index corre- 
sponds to the body number. 

i _xx ( : ) = 1.0 

This is the moment of inertia about the x axis as the body rotates about 
the x axis; the array index corresponds to the body number. 

i-yy(:) = 1-0 

This is the moment of inertia about the y axis as the body rotates about 
the y axis; the array index corresponds to the body number. 

i_zz(:) = 1.0 

This is the moment of inertia about the z axis as the body rotates about 
the z axis; the array index corresponds to the body number. 

i_xy ( : ) = 0.0 

This is the moment of inertia about the x axis as the body rotates about 
the y axis; the array index corresponds to the body number. 

i_xz(:) = 0.0 

This is the moment of inertia about the x axis as the body rotates about 
the z axis; the array index corresponds to the body number. 

i_yz(:) = 0.0 

This is the moment of inertia about the y axis as the body rotates about 
the z axis; the array index corresponds to the body number. 

body_lin_vel ( : , : ) = 0.0 

These are the components of linear velocity; The first array index (rang- 
ing from 1 to 3) corresponds to the x, y, and z components; The second 
array index corresponds to the body number. 

body_ang_vel ( : , : ) = 0.0 

These are the components of angular velocity (degrees/sec); The first 
array index (ranging from 1 to 3) corresponds to the x , y, and z compo- 
nents; The second array index corresponds to the body number. 
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euler_ang( : , : ) = 0.0 

These are the Euler angles (degrees); The first array (ranging from 1 to 
3) corresponds to the rotation angle components; the second array index 
corresponds to the body number. 

gravity_dir (1 : 3) = 0.0, 0.0, -1.0 

This is a unit length gravity vector. 

gravity_mag = 32.2 

This is the magnitude of the gravity vector (default units: ft/ sec 2 ). 
n_extf orce ( : ) = 0 

This is the number of imposed external forces, excluding gravity. The 
array index corresponds to the body number. 

n_extmoment ( : ) =0 

This is the number of imposed external moments; the array index corre- 
sponds to the body number. 

f ile_extforce( : , : ) = ’’ 

This file specifies the external forces; the first array (ranging from 1 
to n_extforce) corresponds to the external force number. The second 
array index corresponds to the body number. 

f ile_extmoment ( : , : ) = ’’ 

This file specifies the external moments; the first array (ranging from 1 
to n_extforce) corresponds to the external force number. The second 
array index corresponds to the body number. 

ignore_x_aeroforce( : ) = .false. 

Flag to ignore the influence of the x-component of the aerodynamic force 
on the 6-DOF motion of the body; the array index corresponds to the 
body number. 

ignore_y_aeroforce( : ) = .false. 

Flag to ignore the influence of the ^/-component of the aerodynamic force 
on the 6-DOF motion of the body; the array index corresponds to the 
body number. 

ignore_z_aeroforce( : ) = .false. 

Flag to ignore the influence of the z-component of the aerodynamic force 
on the 6-DOF motion of the body; the array index corresponds to the 
body number. 
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ignore_x_aeromoment ( : ) = .false. 

Flag to ignore the influence of the ^-component of the aerodynamic 
moment on the 6-DOF motion of the body; the array index corresponds 
to the body number. 

ignore_y_aeromoment ( : ) = .false. 

Flag to ignore the influence of the ^/-component of the aerodynamic mo- 
ment on the 6-DOF motion of the body; the array index corresponds to 
the body number. 

ignore_z_aeromoment ( : ) = .false. 

Flag to ignore the influence of the ^-component of the aerodynamic mo- 
ment on the 6-DOF motion of the body; the array index corresponds to 
the body number. 

print_sixdof .summary = .false. 

Print out a summary of the 6-DOF data for each body at each time step, 
from within the 6-DOF solver itself; useful for verifying that the 6-DOF 
library is getting the correct data from FUN3D 

use.specif ied_aero_data = .false. 

Use aero forces and moments read from file(s) instead of the computed 
values (used for validating 6-DOF library implementation). When this 
option is used, files must be specified for ALL bodies moving under 6- 
DOF. For body N, the file name must be named specified_aero_data_bodyN.dat 

use_restart _mass_properties = .false. 

Use mass and moments of inertia from the FUN3D restart file instead of 
those in this namelist; only needed FUN3D has modified the mass and 
inertia during the simulation. 
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B.5.7 ^aeroelastic modal data 

This namelist specifies modal data for static and dynamic aeroelastic analysis 
via time integration of the structural dynamics equations (see for example [68]). 

&aeroelastic_modal_data 
plot_modes 
nmode ( : ) 
gref 1 ( : ) 
uinf ( : ) 
qinf ( : ) 
gdispO ( : , : ) 
gvelO ( : , : ) 
gf orceO( : , : ) 
gmass ( : , : ) 
freq( : , : ) 
damp ( : , : ) 

genf or ce_include_ shear 
moddf 1 ( : , : ) 
moddf l_amp( : , : ) 
moddf l_freq( : , : ) 
moddf l_tO( : , : ) 
moddf l_add( : , : ) 
mode_f ile_f ormat 

/ 

plotunodes = .false. 

This generates tecplot files of each mode shape added to the body surface. 
These can be inspected these to insure the validity of input modal surface 
data. 

nmode ( : ) =0 

This is the number of aeroelastic modes used to represent the structural 
deformation; the array index indicates the body number. 

grefl(:) = 1.0 

This is the scaling factor between CFD grid units and the structural 
dynamics equation units; the array index indicates the body number. 

uinf ( : ) - 0.0 

This is the freestream velocity, in structural dynamics equation units; 
the array index indicates the body number. 

qinf ( : ) = 0.0 

This is the freestream dynamic pressure, in structural dynamics equation 
units; the array index indicates the body number. 


= .false. 
= 0 
= 1.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= .false. 
= 0 
= 0.0 
= 0.0 
= 0.0 
= 0 


299 



gdispO( : , : ) =0.0 

This is the generalized displacement of a specified mode at the starting 
time step. It is used to perturb a mode to excite a dynamic response. 
The first array index indicates the mode number and the second array 
index indicates the body number. 

gvelO ( : , : ) = 0.0 

This is the generalized velocity of a specified mode at the starting time 
step. It is used to perturb a mode to excite a dynamic response. The 
first array index indicates the mode number and the second array index 
indicates the body number. 

gf orceO ( : , : ) = 0.0 

This is the generalized force of a specified mode at the starting time 
step. It is used to perturb a mode to excite a dynamic response. The 
first array index indicates the mode number and the second array index 
indicates the body number. 

gmass ( : , : ) = 0.0 

This is the generalized mass of a specified mode. The first array index 
indicates the mode number and the second array index indicates the 
body number. 

freq( : , : ) = 0.0 

This is the frequency of specified mode, in rad/sec. The first array index 
indicates the mode number and the second array index indicates the 
body number. 

damp( : , : ) = 0.0 

This is the critical damping ratio (z) of the specified mode. The first 
array index indicates the mode number and the second array index in- 
dicates the body number. 

genf orce_include_shear = .false. 

This includes the shear-stress contribution in the generalized force com- 
putation. By default, only the pressure contribution is included in the 
generalized forces, which is historically common practice. 

moddf 1 ( : , : ) =0 

This is the type of time-varying mode perturbation. The first array 
index indicates the mode number and the second array index indicates 
the body number. 
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‘ -1 ’ is the modal displacement and velocity held fixed at the initial 
values specified by gdispO and gvelO, respectively. 

‘ 0 ’ is no modal perturbation. 

‘ 1 ’ is a harmonic modal oscillation. 

‘ 2 ’ is a Gaussian pulse modal deflection. 

‘ 3’ is a step pulse modal deflection. 

‘5’ specifies simultaneous inputs for reduced order model, 
moddf l_amp( : , : ) = 0.0 

This is the amplitude of mode perturbation. The first array index indi- 
cates the mode number and the second array index indicates the body 
number. 

moddf l_freq( ) = 0.0 

This is the frequency of mode perturbation. If moddf 1=2, it is the Gaus- 
sian pulse half-life. The first array index indicates the mode number and 
the second array index indicates the body number. 

moddf l_t0( ) = 0.0 

If moddf 1=1, this is the dimensional time at which the sinusoidal pertur- 
bation starts. If moddf 1=2, this is the dimensional time of the center of 
the Gaussian pulse. If moddf 1=3, this is the start time of a step pulse. 
The first array index indicates the mode number and the second array 
index indicates the body number. 

moddf l_add( ) = 0 

This determines how the modal perturbation is applied. The first array 
index indicates the mode number and the second array index indicates 
the body number. 

‘ 0 ’ replaces the perturbation with the static aeroelastic solution. 

‘ 1 ’ adds the perturbation to an existing static aeroelastic solution (if 
one exists). 

mode_f ile_f ormat = ’ ascii ’ 

This indicates the type and format of the mode-shape files that are read 
by the code. mode_file_f ormat = ’ ascii’ indicates the files are ASCII 
Tecplot files, with a file extension .dat; mode_f ile_f ormat = ’ stream’ 
indicates binary (stream) DDF files, with a file extension .ddfb. 
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B.5.8 ^composite overset mesh 


This namelist provides the input for SUGGAR++ (see the documentation 
supplied with SUGGAR++ for details). 

&composite_overset_mesh 
input_xml_f ile = ' ' 

/ 


input _xml_f ile = J ’ 

This is the hie containing the XML commands for SUGGAR++. Specify 
the same Input. xml hie that was used to generate the initial composite 
grid with the “stand-alone” SUGGAR++ code. 
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B.5.9 &body motion trim 

This namelist provides the input for trimming a moving body to match se- 
lected trim targets. Trim is achieved by moving one or more bodies via rota- 
tion, translation, or modal amplitude. This option often relies on parent-child 
composite bodies. For example, a wing composite body (the parent) may be 
comprised of a main element (a child) and a flap element (another child). If 
the wing composite body is to be trimmed to match both a lift target and a 
pitching moment target, the lift target can be achieved by adjusting the rota- 
tion angle of the wing composite body, and the moment target can be achieved 
by adjusting the rotation angle of the flap element. An imposed restriction is 
that each trim target is achieved by moving a single body; that single body 
could however be a composite parent-child body 

&body_motion_trim 
trim_ref _f rame 
n_trim_targets( : ) 
trim_variable ( : , : ) 
trim_value ( : , : ) 
body_used_f or_trim( : , : ) 
motion_used_f or_trim( : , :) 
mode_used_f or_trim( : , 
per_step_limit ( : , : ) 
update_f requency ( : , : ) 
tr im_ j acobian ( : , : , : ) 

/ 

trim_ref .frame = ’body’ 

This sets the reference frame in which trim targets are to be satisfied. 
Note that wind-aligned trim targets (Cl and Cd) are unaffected by the 
choice of trim_ref .frame. 

n_trim_targets ( : ) = 0 

This sets the number of trim targets for the body; the array index cor- 
responds to body number of the body to be trimmed. 

‘ 0 :max_trim_targets ’ up to three simultaneous trim targets per body; 
trim_variable( : , : ) = ’none’ 

This specifies the force/moment variables to trim to; the array index 
1 corresponds to the trim target from 1 to n.trim.targets set for the 
body; the array index 2 corresponds to the body number of the body to 
be trimmed. 

‘cl’ trims to a specified lift coefficient 
‘ cd ’ trims to a specified drag coefficient 


= 'body' 
= 0 

= ' none ' 
= 0.0 
= 0 

= ' none ' 
= 0 
= 0.0 
= 1 
= 0.0 
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‘ cw’ trims to a specified weight coefficient; weight is assumed to act in 
the (negative) z-direction. Trim is computed as if a thrust is applied 
along the body x-axis to counterbalance drag; if the body x-axis is not 
aligned with the inertial x-axis, this thrust will also have a contribution 
in the inertial z-direction. 

‘ cx ’ trims to a specified force coefficient in the x-direction 

‘ cy ’ trims to a specified force coefficient in the y-direction 

‘ cz ’ trims to a specified force coefficient in the z-direction 

‘ cmx ’ trims to a specified moment coefficient about the x-axis 

‘ cmy ’ trims to a specified moment coefficient about the y-axis 

‘ cmz ’ trims to a specified moment coefficient about the z-axis 

trim_value ( : , : ) = 0.0 

This specifies the desired numerical values of the trim variables at the 
time condition; the array index 1 corresponds to the trim target from 1 
to n_trim_targets set for the body; the array index 2 corresponds to 
the body number of the body to be trimmed. 

body_used_f or_trim( : , : ) = 0 

This specifies the body number of the body that is moved to achieve the 
trim target; the array index 1 corresponds to the trim target from 1 to 
nvtrimvtargets set for the body; the array index 2 corresponds to the 
body number of the body to be trimmed. 

motion_used_f or_trim( : , : ) = ’none’ 

This specifies the type of body motion used to achieve the trim target; the 
array index 1 corresponds to the trim target from 1 to nvtrimvtargets 
set for the body; the array index 2 corresponds to the body number of 
the body to be trimmed. 

‘ rotate J trims by rotating the body_used_f or.trim 

‘ translate 5 trims by translating the body_used_f or_trim 

'mode’ trims by adjusting modal amplitude of the body_used_f or.trim 

mode_used_f or_trim( : , : ) = 0 

This specifies the aeroelastic mode number used to achieve the trim 
target; only used for modal aeroelastic simulations, and only active when 
motion_used_for_triIn= , mode , ; the array index 1 corresponds to the 
trim target from 1 to n_trim_targets set for the body; the array index 
2 corresponds to the body number of the body to be trimmed. 
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per_step_limit ( : , : ) = 0.0 

This specifies the maximum amount that the motion_usecLf orvtrim can 
change during each attempt to achieve trim; if the motion is rotation, 
the units are degrees; if translation, the units are grid units; if modal 
amplitude, the units are (I have no idea); the array index 1 corresponds 
to the trim target from 1 to n_trim_targets set for the body; the array 
index 2 corresponds to the body number of the body to be trimmed. 

update_f requencyC : , : ) = 1 

This specifies the frequency with which the trim variable is updated 
trim_jacobian( : , : , : ) = 0.0 

This specifies the sensitivities of the specified trira_variable(s) to a 
change in the specified motion_used_f or_trim(s). Thus it is an n_trim_targets 
x n_trim_targets array for each body with trira_control = ’ bodyunotion’ . 
The array index 1 corresponds to the trim variable, array index 2 cor- 
responds to the control motion, the array index 3 corresponds to the 
body number of the body to be trimmed. The sign of the entries is 
important. For example, if the trim variable is lift, and the motion is 
rotation, then if an increase in the rotation angle produces an increase 
in lift, then the sign of that entry in trim.jacobian should be positive. 
Conversely, if an increase in rotation angle produces a decrease in lift, 
then the sign of that entry in trim_jacobian should be negative. If the 
motion_used_f or_trim is rotation, the sensitivity is assumed to be input 
per degree. 
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B.6 rotor, input 


Fun3D is capable of modeling a rotating blade system using different levels of 
approximation. In order of increasing complexity /fidelity /cost, rotor systems 
may be analyzed using either a time-averaged actuator disk, or via first prin- 
ciples modeling of the moving, articulated, rotor blades using overset, moving 
grids. The actuator method utilizes momentum/energy source terms to rep- 
resent the influence of the rotating blade system. Use of the source terms 
simplifies grid generation, since the actuator surfaces do not need to be built 
into the computational grid. However, the computational grid should have 
some refinement in the vicinity of the actuator surfaces to obtain accurate 
results. The steady-state actuator disk capability was originally implemented 
by Dave O’Brien, at the time a PhD candidate at Georgia Tech. [69] O’Brien 
also initiated the overset capability in Fun3D, which was later extended and 
coupled to a rotorcraft comprehensive code by Biedron et al. [70] 

The rotor. input hie is used primarily for specifying input quantities related 
to an actuator surface model for rotor /propeller combinations. When using 
overset, moving grids and/or coupling Fun3D to a rotorcraft comprehensive 
code for a more detailed simulation, a limited number of the input fields in 
the rotor. input hie are also required. The helds required for coupled ro- 
torcraft simulations include (required for coupled simulation) in the variable 
description. The command line option — rotor is required for both types of 
analysis. 

Fun3D can also use the actuator disk library developed by Dave O’Brien 
for the Department of Defense HI-ARMS/CREATE/HELIOS project, Soft- 
ware Module for Engineering Methods of Rotor Dynamics (SMEMRD). The 
Fun3D team is unable to provide technical support for SMEMRD; please 
contact Dave O’Brien directly for assistance (David.ObrienJr@us.army.mil). 
SMEMRD adds the ability to trim to thrust values and use airfoil lookup 
tables. The --hiarms_rotor command line option activates the SMEMRD 
model. 

The two parameters used to set the flight condition and force/moment coef- 
ficient normalization in compressible rotorcraft simulations are mach_number in 
fun3d.nral and Vinf_Ratio in rotor. input. To nondimensionalize the forces 
with the rotor tip velocity, set mach_number to the tip mach number and 
Vinf_Ratio to the ratio of freestream velocity to rotor tip velocity. When 
mach_number is the tip mach number then reynolds_number should be set to 
the corresponding tip Reynolds number. To nondimensionalize the forces with 
the freestream velocity, set mach_number to the freestream mach number and 
Vinf_Ratio to one. The Vinf -Ratio will still affect the force nondimension- 
alization as described above, for incompressible solutions. 

A sample rotor, input file is shown below for a conventional main rotor 
and tail rotor helicopter. 
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# Rotors 

Vinf _Ratio 

Write Soln 

Force_ref 

Moment_ref 


2 

0.1 

50 

1.0 

1.0 







Rotor Type 

Load Type 

# Radial 

# Normal 

Tip Weight 


1 

0 

50 

720 

0.0 


X0_rotor 

Y0_rotor 

Z0_rotor 

phil 

phi2 

phi3 

0.00 

0.00 

0.00 

0.00 

-5.00 

0.00 

Vt_Ratio 

Thrust Cof f 

TorqueCof f 

psiO 

PitchHinge 

DirRot 

1.00 

0.005 

0.00 

0.00 

0.0 

0 

# Blades 

TipRadius 

RootRadius 

BladeChord 

FlapHinge 

LagHinge 

4 

1.00 

0.00 

0.05 

0.00 

0.00 

LiftSlope 

alpha , L=0 

cdO 

cdl 

cd2 


6.28 

0.00 

0.002 

0.00 

0.00 


CL_max 

CL_min 

CD_max 

CD_min 

Swirl 


1.50 

-1.50 

1.50 

-1.50 

0 


ThetaO 

ThetaTwist 

Thetals 

Thetalc 

Pitch-Flap 


5.00 

-2.00 

0.00 

0.00 

0.00 


# FlapHar 

BetaO 

Betals 

Betalc 



0 

0.00 

0.00 

0.00 



Beta2s 

Beta2c 

Beta3s 

Beta3c 



0.00 

0.00 

0.00 

0.00 



# LagHar 

DeltaO 

Deltals 

Deltaic 



0 

0.00 

0.00 

0.00 



Delta2s 

Delta2c 

Delta3s 

Delta3c 



0.00 

0.00 

0.00 

0.00 








Rotor Type 

Load Type 

# Radial 

# Normal 

Tip Weight 


1 

0 

100 

720 

0.0 


X0_rotor 

Y0_rotor 

Z0_rotor 

phil 

phi2 

phi3 

1.00 

0.00 

0.00 

90.00 

0.00 

0.00 

Vt_Ratio 

Thrust Cof f 

TorqueCof f 

psiO 

PitchHinge 

DirRot 

1.25 

0.001 

0.00 

0.00 

0.0 

0 

# Blades 

TipRadius 

RootRadius 

BladeChord 

FlapHinge 

LagHinge 

3 

0.20 

0.00 

0.01 

0.00 

0.00 

LiftSlope 

alpha, L=0 

cdO 

cdl 

cd2 


6.28 

0.00 

0.002 

0.00 

0.00 


CL_max 

CL_min 

CD_max 

CD_min 

Swirl 


1.50 

-1.50 

1.50 

-1.50 

1 


ThetaO 

ThetaTwist 

Thetals 

Thetalc 

Pitch-Flap 


8.00 

0.00 

0.00 

0.00 

0.00 


# FlapHar 

BetaO 

Betals 

Betalc 



0 

0.00 

0.00 

0.00 



Beta2s 

Beta2c 

Beta3s 

Beta3c 



0.00 

0.00 

0.00 

0.00 



# LagHar 

DeltaO 

Deltals 

Deltaic 



0 

0.00 

0.00 

0.00 



Delta2s 

Delta2c 

Delta3s 

Delta3c 



0.00 

0.00 

0.00 

0.00 




The header line is where the user specifies the number of rotors, the 
freestream velocity ratio, and how often to output the plot3d loading file. 
The remainder of the file is in a block structure, where each block represents 
the inputs for one rotor. The first line of each block is a text line that can be 
edited to keep the rotors organized for the user. The input values do not have 
to be in a fixed format (spaces and number of decimal points do not matter), 
but the input values do have to be in the correct order as noted by the header 
lines for the individual input parameters. 
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B.6.1 Header 

# Rotors (required for coupled simulation) 

This is the number of actuator surfaces to create. The number of rotor 
input blocks in this file must match the number of rotors specified. 

Vinf _Ratio (required for coupled simulation) 

This is the ratio of the freestream velocity to the the velocity used for 
force normalization. The force normalization velocity is typically the tip 
velocity for rotorcraft applications. 

Write Soln 

This is the frequency (in iterations) of Plot3D rotor loading data output, 
which is pairs of source_grid_00000.p3d and source_data_00000.p3d 
hies. To write once, set Write Soln to steps. 

Force_ref 

This is the conversion factor to obtain forces in alternate units, 

1.0 will output the standard Fun 3D nondimensionalization 

(L 2 re faf e j) / (n Rrotor^up) output standard rotorcraft nondimension- 
alization 

Pref a refLref output dimensional units 
Moment_ref 

This is the conversion factor to obtain moments in alternate units. 

1.0 will output the standard Fun 3D nondimensionalization 

(L'i e faf e f) / (n R) otor V(j p ) will output standard rotorcraft nondimension- 
alization 

Pref a refLref w '^ output dimensional units 

B.6.2 Actuator Surface Model 
Rotor Type 

Type of rotor model to apply, 

1 models the rotor as an actuator disk. 

2 models the rotor as actuator blades. 

Load Type 

Type of loading to apply to the rotor model. 
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1 is a pressure jump based on ThrustCoeff that is constant over the 

disk. This loading does not model swirl. 

2 is a pressure jump based on ThrustCoeff that increases linearly with 

radius. This loading does not model swirl. 

3 is blade element based loading based defined by the blade element 

parameters defined in section B.6.6 and section B.6.7. This loading 
can model swirl if Swirl=l. 

4 is user-specified source geometry and strength. Not recommended un- 

less you have experience in actuator disk modeling. See the subrou- 
tine read_user_source2 in LibF90/rotors.f90 for input format. 

5 is user specified thrust and torque radial distributions in the file 

propeller_propertiesN.dat, where N is the rotor index. The first 
line of the file is the number of radial stations. The following lines 
have three numbers per station, with r/R, dCr / d(r / R ) , dCqjdir / R) 
This file sets the thrust and torque loading directly, so ThrustCoeff 
and TorqueCoeff are ignored. This loading can model swirl if 
Swirl=l. 

6 is a body force based on on the optimal distribution of Goldstein 

[71] implemented as described by Stern, Kim, and Patel. [72] Use 
ThrustCoeff to set the thrust and TorqueCoeff to produce swirl 
(with Swirl=l). 

# Radial 

This is the number of sources to distribute along the blade radius. This 
should be set to approximately match the resolution of the volume grid, 
otherwise a suggested value is 100. 

# Normal 

This is the number of sources to distribute along the circumferential 
direction. This should be set to approximately match the resolution 
of the volume grid. For Rotor Type=l, 720 is suggested for a source 
every 0.5 degrees. For Rotor Type=2, 20 points in the chord direction is 
suggested. 

Tip Weight 

This is the hyperbolic weighting factor for distributing sources along the 
blade radius. A suggested value is 0.0, which yields uniform distribution. 
A value larger than 2.0 is not advised because it places too many sources 
at the blade tip. 
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B.6.3 Rotor Reference System 

X0_rotor (required for coupled simulation) 

This is the x coordinate of the hub center of rotation, in grid units. 
YCLrotor (required for coupled simulation) 

This is the y coordinate of the hub center of rotation, in grid units. 
ZCLrotor (required for coupled simulation) 

This is the z coordinate of the hub center of rotation, in grid units, 
phil 

This is the first Euler angle describing a rotation about the x axis, in 
degrees. For a propeller oriented in the x-positive direction, this should 
be 0. 
phi2 

This is the second Euler angle describing a rotation about the 02 axis, in 
degrees. For a propeller oriented in the x-positive direction, this should 
be -90. 

phi3 

This is the third Euler angle describing a rotation about the 63 axis, in 
degrees. For a propeller oriented in the ^-positive direction, this should 
be 0. 

The Euler angles must be input correctly to obtain the correct orientation 
of the source based actuator disk. The following example illustrates how to 
determine these angles. Figure B5 depicts the rotations phil = 10, phi2 = 
— 15, and phi3 = 15. Initially, the thrust is assumed to be in the z direction 
and the disk is located in the x — y plane. The first rotation of phil about 
the x axis takes the x — y — z system to the cp — a 2 — a 3 system shown in red. 
The second rotation of phi2 about the a 2 axis takes the a\ — a 2 — a 3 system 
to the £>1 — fc> 2 — & 3 system shown in green. The final rotation of phi3 about 
the fe 3 axis takes the b\ — fe 2 — fe 3 system to the rotor reference system shown in 
blue. The black circle represents the initial disk orientation and the blue circle 
represents the final disk orientation. In general phil and phi2 are sufficient 
to define the thrust orientation. The variable phi3 only changes the location 
of the zero azimuth angle definition for the rotor. 

B.6.4 Rotor Loading 

Vt_Ratio (required for coupled simulation) 

This is the ratio of the tip speed to the velocity used for force nor- 
malization, which is mach_number for compressible simulations. For 
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Figure B5: Rotor disk Euler angles. 


Load Type = 3, Load Type = 5, and Load Type = 6 a negative value 
will reverse the rotation direction. The propeller convention is J = ^, 
where V a is speed of advance (true airspeed), n is revolutions per unit 
time, and D is diameter, i.e, Vt_Ratio= j. 

ThrustCof f 

This is the rotor thrust coefficient defined as, Ct = Thrust / (7rp re fR 2 (VlDim.R) 2 ), 
when Load Type=l, Load Type=2, or Load Type=6. The blade element 
model does not trim to specified thrust coefficient. The propeller con- 
vention is Kt = Thrust / ( p re fn 2 D l ), where n is revolutions per unit 
time, and D is diameter, i.e, ThrustCoff= ^ Kt ■ 

TorqueCof f 

This is the rotor torque coefficient defined as, Cq = Torque / (tt p re f R 3 (Q Dim R) 2 ) , 
when Load Type=6. The blade element model is not effected by spec- 
ified torque coefficient. The propeller convention is Kq = Torque / 
(pref^D 5 ), where n is revolutions per unit time, and D is diameter, i.e, 
ThrustCoff= J 'zKq . 


B.6.5 Blade Parameters 

psiO (required for coupled simulation) 

This is the initial azimuthal position of blade one, in degrees; the azimuth 
position is defined as zero when the blade is oriented along the x-axis 
with the tip at the most positive x location. 

PitchHinge (required for coupled simulation ) 

This is the radial position of the blade pitch hinge normalized by tip 
radius. 
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DirRot (required for coupled simulation) 

This is the direction of rotor rotation. Zero is counter-clockwise rota- 
tion and one is clockwise rotation. This option only applies to coupled 
simulation, not actuator models. 

# Blades (required for coupled simulation) 

This is the number of rotor blades. It is only used for Load Type=3 and 
overset rotor simulations. 

TipRadius (required for coupled simulation) 

This is the radius of the blade, in grid units. 

RootRadius (required for coupled simulation) 

This is the radius of the blade root, in grid units. It accounts for the 
cutout region immediately surrounding the hub. 

BladeChord (required for coupled simulation) 

This is the chord length of the blade, in grid units. It can only handle 
rectangular blade planforms and is only valid for Load Type=3. 

FlapHinge (required for coupled simulation) 

This is the radial position of the blade flap hinge normalized by tip 
radius. 

LagHinge (required for coupled simulation) 

This is the radial position of the blade lag hinge normalized by tip radius. 

B.6.6 Blade Element Parameters for Load Type=3 

These inputs are used to set the blade element lift and drag curves according 
to: 

Cl = LiftSlope(o: — Q i=0 ) (B7) 

and 

Co = cdO + cdl a + cd2 a 2 (B8) 

LiftSlope 

This is the lift curve slope per radian, 
alpha, L=0 

This is the zero lift angle of attack, in degrees. 

cdO, cdl, and cd2 

These are the quadratic drag polar coefficients; where cdl is per radian 
and cd2 is per radian squared. 
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CL_max and CL_min 

These limiters to control the lift coefficient beyond the linear region. 
CD_max and CD_min 

These limiters to control the drag coefficient. 

Swirl 

0 neglects the sources terms that create rotor swirl. 

1 the swirl inducing source terms. 

B.6.7 Pitch Control Parameters for Load Type=3 

These inputs are used to specify the pitch/flap controls according to: 

6 = ThetaO + ThetaTwist ( r/R ) + Thetalc cos(0) + Thetals sin('0) (B9) 

ThetaO 

This is the collective pitch defined at r/R— 0, in degrees. 

ThetaTwist 

This is the total amount of linear blade twist from the origin to the blade 
tip, in degrees. 

Thetals 

This is the longitudinal cyclic pitch input, in degrees. 

Thetalc 

This is the lateral cyclic pitch input, in degrees. 

Pitch-Flap 

Pitch-Flap coupling parameter [not implemented]. 

B.6.8 Prescribed Flap Parameters 

These inputs are used to specify the flap harmonics according to: 

/3 = BetaO + Betals sin(0) + Betalc cos(0) 

+Beta2s sin(20) + Beta2c cos(20) (BIO) 

+Beta3s sin(30) + Beta3c cos(30) 

# FlapHar 

This is the number of flap harmonics to include. The valid input range 
is zero to three. 
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BetaO 

This is the coning angle, in degrees. 

Betals and Betalc 

This is the first flap harmonics, in degrees. 

Beta2s and Beta2c 

This is the second flap harmonics, in degrees. 

Beta3s and Beta3c 

This is the third flap harmonics, in degrees. 

B.6.9 Prescribed Lag Parameters 

These inputs are used to specify the lag harmonics according to: 

5 = DeltaO + Deltals sin(0) + Deltaic cos(0) 

+Delta2s sin (2-0) + Delta2c cos(20) (Bll) 

+Delta3s sin(30) + Delta3c 008(30) 

# LagHar 

This is the number of lag harmonics to include. The valid input range 
is zero to three. 

DeltaO 

This is the coning angle, in degrees. 

Deltals and Deltaic 

This is the first lag harmonics, in degrees. 

Delta2s and Delta2c 

This is the second lag harmonics, in degrees. 

Delta3s and Delta3c 

This is the third lag harmonics, in degrees. 


314 



B.7 tdata 


This file defines the gas model when eqn_type = ’generic’. A keyword is 
required on the first line of tdata. Many of these models require additional 
information as detailed in each keyword section. 

Some keywords require a list the species. For these keywords, additional 
groups of species can be specified for boundary conditions after a blank line. 
If new species are introduced in subsequent instances their mass fractions are 
automatically initialized to zero at any previous inflow boundary. All the 
species entries in this hie are available as reactants throughout the entire how 
held. 

B.7.1 perfect gas Keyword 

A perfect gas can be modeled with the perf ect_gas keyword. The parameters 
can be explicitly defined in tdata by the namelist &species_properties. The 
namelist in tdata has different variables than the &species_properties in 
species_thermo_data. Here is an example of the namelist with defaults that 
are all given in SI units, 

perf ect_gas 
&spe cies_properti.es 
gamma = 1.4 

mol_wt = 28.8 

sutherl = 0 . 1458205E-05 

suther2 = 110.333333 
prand = 0.72 

/ 

Where gamma is the gas specihc heat ratio, mol_wt is the gas molecular weight, 
prand is the gas Prandtl number, and sutherl and suther2 are the hrst and 
second Sutherland’s viscosity coefficients, Si and s 2 , in 

T 3/2 

» = si - ( B12 ) 

1 + S 2 

These defaults are used if the &species_properties namelist or any of its 
variables are omitted. 

B.7. 2 equilibrium_air_t Keyword 

The equilibrium_air_t keyword engages the Tannehill curve hts for thermo- 
dynamic and transport properties of equilibrium air. [73] This keyword does 
not require additional lines. 

equilibrium_air_t 
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B.7.3 equilibrium air r Keyword 


The equilibrium_air_r keyword engages the Tannchill curve fits for transport 
properties and a table look-up for equilibrium gases [74], This keyword does 
not require additional lines. 

equilibrium_air_r 
B.7.4 one Keyword 

This one-temperature (1-T) model assumes that all the species are thermally 
in equilibrium state; the translational temperature T and vibrational tempera- 
ture T v are equal. This is a mixture of thermally perfect gases and multi-species 
transport. In this example, only molecular oxygen and nitrogen are present 
on the inflow boundary, but atomic nitrogen and oxygen and nitric oxide may 
be produced elsewhere in the flow field due to chemical reactions. The inflow 
boundary mass fraction of molecular oxygen and nitrogen is given next to their 
symbols. Mass fractions should sum to one. 

one 

N2 .767 
N 

02 .233 

0 

NO 

B.7.5 two Keyword 

This two-temperature (2-T) model assumes that energy distribution in the 
translational and rotational modes of heavy particles (not electrons) are equili- 
brated at translational temperature T and all other energy modes (vibrational, 
electronic, electron translational) are equilibrated at vibrational temperature 
T v . In this example, the gas is assumed to be a mixture of 11 thermally perfect 
gases. The inflow boundary mass fraction of molecular oxygen and nitrogen is 
given next to their symbols. Mass fractions should sum to one. Other products 
are the results of chemical reactions flow field. 

two 

N2 .767 
N 

02 .233 

0 

NO 

02 + 

0 + 

N0+ 

e- 
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B.7.6 FEM Keyword 


This Free-Energy Minimization (FEM) model causes the species continuity 
equations to be replaced with elemental continuity equations and equilibrium 
relations for remaining species. In this example, the gas is assumed to be a 
mixture of 11 thermally perfect gases. The inflow boundary mass fraction of 
molecular oxygen and nitrogen is given next to their symbols. Mass fractions 
should sum to one. Other products are the results of chemical reactions flow 
field. 

FEM 

N2 .767 
N 

02 .233 

0 

NO 

02 + 

0 + 

N0+ 

e- 

B.8 species_thermo_data 

The species_thermo_data hie is the master hie for species thermodynamic 
data. The majority of simulations do not require changes to this hie. Investi- 
gating other sources of thermodynamic data is the only reason to edit this hie. 
If the hie is not found in the local run directory, it is assumed to be located in 
the [install-prefix] /share/physics_modules directory. See section A. 3 
for [install-prefix]. 

Each species record consists of the species name, a &species_properties 
namelist, the number of thermodynamic property curve ht ranges, and the 
curve ht coefficients for each range. [75] No blank line is allowed in this 
hie. This &species_properties namelist has different variables than the 
&species_properties in tdata. The elements of the &species_properties 
namelist are: 
mol_wt 

This sets the molecular weight of the particle. It is always required. 

molecule = .false. 

This is denotes the the species a molecule (composed of more than one 
atom); 

ion = .false. 

This is denotes the the species a charged particle. Do not set it for neu- 
trals and electrons. This will initializes electron-neutral energy exchange 
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cross section and sum of the charges. 

charge = 0 

This is an integer number to determine number of positive charges in 
particle. It should only be used with ion = .true. 

elec_irapct_ion = -l._dp 

This sets the energy for neutrals ion=. false, that is required to liberate 
an electron when the neutral impact a free electron, in units of electron 
volts (eV). 

siga( : ) = - 1 . _dp 

This is an array of three real numbers, which correspond to the curve 
fit coefficients for electron-neutron energy exchange. The cross section 
is defined as 

<y en = a + bT + cT 2 (B13) 

where cr en is the electron-neutron energy exchange collision cross section 
in m 2 . The variables a, b , and c are the curve fit coefficients and T is 
the gas temperature. [76,77] For example, siga=7.5e-20 , 0, 0. 

disoc_ener = 0._dp 

This is the dissociation energy of molecule in electron volts (eV). 

alantel = 0._dp 

This is the Landau- Teller constant to compute vibrational relaxation 
time for molecule. [78,79]. It is required when molecule=.true.. 

cprtO = 0._dp 

This non-dimensional real number defines translational-rotational heat 
capacity. It is normalized by the gas constant and is equal to 

f + 2 

cprtQ = — — — (B14) 

where / is the number of degrees of freedom in translation and rota- 
tion. The defaults for atoms and diatomic molecules are 2.5 and 3.5, 
respectively. 

A portion of the species _thermo_data that provides thermodynamic prop- 
erties of carbon is shown below. 


C i 
&species_properties 2 
molecule = .false. 3 
ion = .false. 4 
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5 


charge = 0 

elec_impct_ion = 11.264 
siga = 7.5e-20, 5.5e-24, -l.e-28 
mol_wt = 12.01070 
/ 

3 


0 . 64950315E+03 
0 . 19801337E-07 
0 . 85457631E+05 
-0 . 12891365E+06 
0.17420927E-06 
0 . 84105978E+05 
0 . 44325280E+09 
0.66495953E-06 
0 . 23552734E+07 


-0 . 96490109E+00 
-0. 16061440E-10 
0 . 47479243E+01 
0 . 17 195286E+03 
-0 . 29028 178E- 10 
0 . 41300474E+01 
-0 . 28860184E+06 
-0.22300788E-10 
-0 . 64051232E+03 


0 . 25046755E+01 
0 . 53144834E-14 
200.000 1000 
0 . 26460444E+01 
0. 16421824E-14 
1000.000 6000 
0 . 7737 1083E+02 
0 . 28993887E-15 
6000.000 20000 


-0.12814480E-04 

0.00000000E+00 

000 

-0.33530690E-03 

0.00000000E+00 

000 

-0.97152819E-02 

0.00000000E+00 

000 


n 

12 

13 

14 

15 

16 

17 

18 
19 


The species name is defined in line 1. Between lines 2 and 9 species properties 
are defined. Line 10 shows that there are three thermodynamic property curve 
fits for temperature ranges of 200 K < T < 1,000 K, 1,000 K < T < 6,000 K, 
and 6,000 K < T < 20,000 K. Each data range consists of 12 real numbers. 
Four real numbers must be given on each line. The first 10 real numbers are the 
thermodynamic curve fit coefficients, and the last two real numbers identify 
the temperature range for the given curve fit coefficients. These coefficients 
are used to calculate the following thermodynamic properties 


c p {T)/R = aiT 2 + a 2 T 1 + + (I4T + a 5 T 2 + a 6 T 3 + (I7T 4 (B15) 

h(T)/RT = — a{T 2 -\-d2T T+a3 + a4 — + 05-— + Ug— — I- 0 , 7 — — (B16) 

Z O vt 0 -L 

jn — 2 rji 2 rp 3 rp 4 

s(T)/R = — d\— d%T 1 + <23/77 T + G^T + ag— — K<26 — — Lci7^- + Gio (B17) 

where T is the gas temperature, R is the universal gas constant, c p , h, and s 
are the species specific heat, enthalpy and entropy, respectively, and a* are the 
provided curve fit coefficients in species_thermo_data. 

The following corrections will be applied if the gas temperature is out of 
the given range for the given curve fit coefficients: 


where 


c r (T) = c r (T*) 

(BIS) 

h(T) = h(T') + (T - T*)cp(T*) 

(B19) 

s(T) = s(T’) + In T Cj>( r) 

(B20) 

rj - ?* f Ti ower for T <1 Ti ower 

T U pper ^ Supper 

(B21) 
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B.9 kinetic data 

The kinetic_data file defines possible chemical reactions and is optional. If 
the hie is not found in the local run directory, it is assumed to be located in 
the [install-prefix] /share/physics_modules directory. See section A. 3 
for [install-prefix] . Reactants and products can be any species defined in 
the species_thermo_data described in section B.8. A sample entry looks like 

02 + M <=> 20 + M 

2 . 000e+21 -1.50 5.936e+04 

teffl = 2 

expl = 0.7 

t_eff_min = 1000. 

t_eff_max = 50000. 

C = 5.0 
0 = 5.0 
N = 5.0 
H = 5.0 
Si = 5.0 
e- = 0 . 

The first line specifies the reaction while line 2 provides three coefficients of 
an Arrhenius- like equation, 

K, = c,rj lf e-°l kT -" (B22) 

where cy is the pre-exponential factor, ij is the power of temperature depen- 
dence on the pre-exponential factor, eo is the Arrhenius activation energy, and 
k is the Boltzmann constant. The arrowheads in line 1 signify the allowed 
directionality of the reaction. The symbol => denotes forward reaction only 
while <=> denotes forward and backward rates are computed. The coefficients 
in line 2 correspond to cy, r/, and eo/k, respectively. For reactions with a 
generic collision partner, M, such as this one, these coefficients correspond to 
Argon; and other collision partners and their efficiencies (multipliers of cy) 
are specified on lines following line 5 and 6, which give the valid temperature 
range for the reaction. The effective temperature, T e yy, is defined according 
to a given integer number in line 3. 

teffl = l,tef f 2 = 1 

This defines the formula to compute the effective temperature T e yy for 
the forward rate and backward rate, respectively. It is engaged for the 
case of thermal nonequilibrium. Options for teff are: 

1: T eff = Ttr 

O . rp rriexpl rji\ — expl 

Z - i e// ~ 1 tr 1 v 


l 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 
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3: T eff ~ T v 


where T tr and T v are translational and vibrational temperatures, respec- 
tively. 

expl = 0.7 

This is the exponent used to define the effective temperature when 
teff 1= 2 (forward rate) or teff 2 = 2 (backward rate). 

rf_max = l.e+20 

This is the upper limit on forward reaction rate in cgs units when 
augment _kinetics_limiting = .true. For unlimited rates as function 
of temperature, see the output hie kinetic_diagnostics_output. 

rf_min = l.e-30 

This is the lower limit on forward reaction rate in cgs units when 
augment _kinetics_limiting= .true. For unlimited rates as function of 
temperature, see the output hie kinetic_diagnostics_output. 

rb_max = l.e+30 

This is the upper limit on backward reaction rate in cgs units when 
augment _kinetics_limiting = .true. For unlimited rates as function 
of temperature, see the output hie kinetic_diagnostics_output. 

rbunin = l.e-30 

This is the lower limit on backward reaction rate in cgs units when 
augment _kinetics_limiting = .true. For unlimited rates as function 
of temperature, see the output hie kinetic_diagnostics_output. 

t_eff_min = 1000. 

This is the minimum temperature for T e ff. This may circumvent stiff 
source terms when computing reaction rates. 

t_eff_max = 50000. 

The maximum temperature for T e ff. This may circumvent stiff source 
terms when computing reaction rates. 

B.10 species_transp_data 

The species_transp_data hie contains log-linear curve ht coefficients for 
species collision cross sections that are defined based on temperature range 
of 2,000-4,000 K. [77] This temperature range spans boundary- layer temper- 
atures for typical hypersonic entry. The curve ht for the given coefficients is 
poor at temperatures below 1,000 K. Higher order curve ht data is available 
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in species_transp_data_0. The file should not be changed by the user unless 
there is a need to investigate other sources of collision cross-section data. If 
the file is not found in the local run directory, it is assumed to be located in 
the [install-prefix] /share/physics_raodules directory. See section A. 3 
for [install-prefix] . An example of the entries in the file is 


Ar Ar 1 
-14.6017 -14.6502 -14.5501 -14.6028 ! trrl32+kestin et al 2 
Ar+ Ar+ 3 
-11.48 -12.08 -11.50 -12.10 4 
Ar N2 5 
-14.5995 -14.6475 -14.5480 -14.5981 ! kestin et al e 
Ar CD 7 
-14.5975 -14.6455 -14.5459 -14.5964 ! kestin et al s 


B.ll species_transp_data_0 

The file species_transp_data_0 provides collision cross section coefficients 
[80,81] for a higher order curve fit data than those that are in the species_transp_data. 
The data in species_transp_data_0 supersedes the data in species_transp_data 
The file should not be changed by the user unless there is a need to investi- 
gate other sources of collision cross-section data. If the file is not found in 
the local run directory, it is assumed to be located in the [install-prefix] 
/share/physics_modules directory. See section A. 3 for [install-prefix]. 

An example of the entries in the file is 


02 N 


111 (c) 

-1. 1453028E-03 
-1.0608832E-03 
1 . 4943783E-04 


1 . 2654140E-02 
1. 1782595E-02 
2 . 0389247E-03 


-2.2435218E-01 
-2. 1246301E-01 
1 . 8536165E-02 


7 . 7201588E+01 
8 . 4561598E+01 
1 . 0476552E+00 


NO N 


111 (c) 

-1 . 57709 18E-03 
-1.47 19259E-03 
2. 1014557E-04 


1 . 9578381E-02 
1 . 8446968E-02 
-3.0420763E-03 


-2.7873624E-01 
-2.6460411E-01 
2 . 5736958E-02 


9 . 9547944E+01 
1 . 0911124E+02 
1 . 0359598E+00 


NO 0 


111 (c) 

-1 . 0885815E-03 
-1.0066279E-03 
1 . 4145458E-04 


1. 1883688E-02 
1. 1029264E-02 
-1 . 924927 IE-03 


-2. 1844909E-01 
-2.0671266E-01 
1 . 7785767E-02 


7 . 5512560E+01 
8 . 2644384E+01 
1 . 0482162E+00 


END END 


110 

0 . 0 . 0 . 0 . 

0 . 0 . 0 . 0 . 
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B.12 harajname list data 

The hara_namelist_data file controls the radiation models used by the Hara 
radiation module. [82,83] It is optional for coupled radiation simulations. If it is 
not present, then the code automatically chooses the radiative mechanisms as- 
sociated with species present in the flowfield that have number densities greater 
than 1000 particles/cm 2 ) Other options are set to the defaults. For users not 
experienced in shock-layer radiation, the recommended default options should 
be used, this hara_namelist_data A default hara_namelist_data is available 
in the PHYSICS_MODULES directory of the Fun3D distribution. 

specifying radiation mechanisms for atomic species: The treatment 

of radiation resulting from atomic lines, atomic bound-free, and free-free pho- 
toionization (referred to here as atomic continuum), and negative ion contin- 
uum is available for atomic carbon, hydrogen, oxygen, and nitrogen. These 
mechanisms are specified through the following binary flags (on=l/off=0). If 
any of these flags are not present in hara_namelist_data, then that flag is set 
to true only if the number density of the associated atomic species is greater 
than 1000 particles/cm 2 somewhere in the flowfield. 

treat, [?] -lines 

A binary flag to enable the treatment of atomic lines for species [?] , 
where [?] can be c, h, n, and o, for atomic carbon, hydrogen, nitrogen 
and oxygen, respectively. 

treat, [?] _cont 

A binary flag to enable the treatment of atomic bound-free and free-free 
continuum for species [?] , where [?] can be c, h, n, and o, for atomic 
carbon, hydrogen, nitrogen and oxygen, respectively. 

treat, [?] _other 

A binary flag to enable the treatment of the negative-ion continuum for 
species [?] , where [?] can be c, h, n, and o, for atomic carbon, hydrogen, 
nitrogen and oxygen, respectively. 

specifying radiation mechanisms for molecular species: The treat- 

ment of radiation resulting from numerous molecular band systems is avail- 
able through the following flags (0 = off, 1 = SRB, 2 = LBL). The smeared 
rotational band (SRB) approach applies a simplified and efficient treatment of 
each molecular band system, which is accurate for optically thin conditions. 
The line-by-line (LBL) approach is a detailed but highly inefficient treatment 
of each molecular band system. The LBL option is not recommended for cou- 
pled radiation-flowfield computations, except for possibly the CO 4+ system, 
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which may be optically thick for Mars entry conditions. If any of these flags 
are not present in hara_namelist_data, then that flag is set to the SRB option 
only if the number density of the associated molecular specie is greater than 
1000 particles/cm 2 somewhere in the flowfield. Additional band systems are 
listed in the following paragraph. These additional band systems are gener- 
ally considered negligible relative to those listed in this section. Therefore, for 
computational efficiency, they are not engaged by default. Definitions of each 
band system and the modeling data applied are discussed in Refs. [82,84], 

treat _band_c2_swan 

A flag activating the C 2 Swan band system. 

treat _band_c2h 

A flag activating the C 2 H band system. 

treat_band_c3 

A flag activating the C 3 and vacuum ultra-violet (VUV) band systems. 

treat _band_cn_red 

A flag activating the CN red band system. 

treat _band_cn_violet 

A flag activating the CN violet band system. 

treat _band_co4p 

A flag activating the CO 4+ band system. 

treat _band_co_bx 

A flag activating the CO B-X band system. 

treat _band_co_cx 

A flag activating the CO C-X band system. 

treat_band_co_ex 

A flag activating the CO E-X band system. 

treat_band_co_ir 

A flag activating the CO X-X band system. 

treat _band_h2_lyman 

A flag activating the H 2 Lyman band system. 

treat_band_h2_werner 

A flag activating the LR Werner band system. 
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treat _band_n2fp 

A flag activating the N2 1 + band system. 

treat _band_n2sp 

A flag activating the N2 2 + band system. 

treat _band_n2pfn 

A flag activating the first-negative band system. 

treat _band_n2_bhl 

A flag activating the N2 Birge-Hopheld I band system. 

treat_band_n2_bh2 

A flag activating the N 2 Birge-Hopheld II band system. 

treat_band_no_beta 

A hag activating the NO beta band system. 

treat_band_no_delta 

A hag activating the NO delta band system. 

treat _band_no_epsilon 

A hag activating the NO epsilon band system. 

additional molecular band systems: This paragraph lists molecular band 

systems available in addition to those listed in the paragraph above. The 
band systems listed here are generally weak emitters and absorbers, and are 
therefore not engaged as a default. Therefore, for these band systems to be 
engaged, the following hags (0 = oh, 1 = SRB, 2 = LBL) must be present 
in the hara_namelist_data hie. The LBL treatment of these bands is not 
recommended. 

treat _band_c2_br 

A hag activating the C2 Ballik-Ramsay band system. 

treat_band_c2_da 

A hag activating the C2 Deslandres-d’Azambuja band system. 

treat _band_c2_fh 

A hag activating the C2 Fox-Herzberg band system. 

treat_band_c2_mulliken 

A hag activating the C2 Mulliken band system. 
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treat _band_c2_phil ip 

A flag activating the C 2 Philips band system. 

treat _band_co3p 

A flag activating the CO 3+ band system. 

treat _band_co_angstrora 

A flag activating the CO angstrom band system. 

treat _band_co_asundi 

A flag activating the CO Asundi band system, 
treat _band_co_triplet 
A flag activating the CO triplet band system. 

treat_band_co2 

A flag activating the CO 2 band system. A value of two activates an 
approximate nonequilibrium model for UV emission, while a value of 
one assumes Boltzmann emission. The LBL treatment of this band is 
not available. 

treat _band_n2_cy 

A flag activating the N 2 Carrol- Yoshino band system, 
treat _band_n2_wj 

A flag activating the N 2 Worley-Jenkins band system. 

treat _band_n2_worley 

A flag activating the N 2 Worley band system. 

treat _band_no_gamma 

A flag activating the NO gamma band system. 

treat _band_no_betap 

A flag activating the NO beta-prime band system. 

treat _band_no_garamap 

A flag activating the NO gamma-prime band system. 

treat _band_o2_sr 

A flag activating the O 2 Schumann-Runge band system, 
treat. [?] _photo_dis 

A binary flag activating the molecular photo-dissociation mechanism [85] 
for [?] specie, where [?] can be 02 or N2. This mechanism is not 
technically a molecular band system. 
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treat. [?] _photo_ion 

A binary flag activating the molecular photo-ionization mechanism [85] 
for [?] specie, where [?] can be 02 or N2. This mechanism is not 
technically a molecular band system. 

treat _no_photo 

A binary flag activating the molecular photo-ionization mechanism [85] 
for NO. 

atomic line models: There are various models available for atomic line radi- 

ation, one of which must be chosen for each specie that engages atomic line ra- 
diation (as specified using treat. [?] .lines). This choice of atomic line model 
is made using the following flags. The listed defaults are applied if the indi- 
vidual flag is not present in hara_namelist.dat a, or if hara_namelist.dat a 
is not present in the working directory. All model types in this category must 
be surrounded by a quotation marks. 

c.atomic.line nnodel, h.atomic.line nnodel 

A character identifier for selecting the atomic line model for atomic car- 
bon or hydrogen. Presently, the only available option is the model com- 
piled in Ref. [84], which is referred to here as the Complete Line Model 
(CLM). Default : ‘elm’ 

n.atomic.line nnodel, o.atomic.linejnodel 

A character identifier for selecting the atomic line model for atomic ni- 
trogen or oxygen. The available models are compiled and compared in 
Ref. [82], which is referred to here as the Complete Line Model (CLM). 
Default : ‘clnd Available models are: 

‘all multiplets’ 

This model treats all lines as grouped multiplets. This significantly 
reduces the number of lines treated as well as the computational 
expense. However, this grouped multiplet approximation will lead 
to errors for non-optically-thin conditions. 

‘ elm’ 

This model, which stands for Complete Line Model, applies the 
individual treatment of strong atomic lines while applying multiplet 
averages for weak lines. This is the recommended model. 

electronic state population models: These flags specify the model ap- 

plied for predicting the electronic state populations of atoms and molecules. 
The listed defaults are applied if the individual flag is not present in 
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hara_namelist_data, or if hara_namelist_data is not present in the working 
directory. All model types in this category must be surrounded by a quotation 
marks, e.g. ‘ 


atomic electronic states 

The electronic state populations for atoms are required for computing atomic 
line and photoionization emission and absorption. The compilation and com- 
parison of the available models are presented in Ref. [83]. 

c_electronic_state, h_electronic_state 

A character identifier for selecting the electronic state model for atomic 
carbon and hydrogen. Available models are (default : ‘boltzmann’): 

1 boltzmann’ 

Applies Boltzmann population of electronic states. 

‘ Gally_lst_order_LTNE’ 

Applies the Gaily first-order local thermodynamic nonequilibrium 
method [86] , which approximately accounts for the non-Boltzmann 
population of atomic states. 

n_electronic_state, o_electronic_state 

A character identifier for selecting the electronic state model for atomic 
nitrogen and oxygen. Available models are (default : ‘CR’): 

‘ boltzmann’ 

Same as for c_electronic_state 

‘ Gally_lst_order_LTNE’ 

Same as for c_electronic_state 

‘ CR’ 

Applies the detailed collisional radiative (CR) model developed in 
Ref. [83], 

f AARC ’ 

Applies the approximate atomic collisional radiative (AARC) model 
developed in Ref. [83]. This model is essentially a curve-fit based 
approximation of the CR model, which allows for improved compu- 
tational efficiency with a slight loss in accuracy. 
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molecular electronic states 


The electronic state populations for molecules are required for computing 
molecular band emission and absorption. The compilation and comparison 
of the available models are presented in Refs. [83,87]. 

molecular_electronic_state 

A character identifier for selecting molecular electronic state for all molec- 
ular band systems. Available models are (default : ‘CR’): 

‘ boltzmann’ 

Applies Boltzmann population of electronic states. 
f CR’ 

Applies a detailed collisional radiative model considering both heavy- 
particle and electron impact transitions. Some molecular states 
are still assumed Boltzmann with this model because no data is 
presently available for the CR model. 

other flags: 

usevtriangles 

A logical flag specifying whether optically-thin atomic lines are modeled 
as triangles to reduce computational time. This option has shown to 
result in a negligible loss of accuracy while greatly reducing the compu- 
tational time, [82] and is therefore recommended. Default : .true. Note: 
This flag is automatically set to .true, when n_ or o_atomic_line unodel= 

‘ elm’ — see atomic line models earlier in this section. 

use_edge_shift 

A logical flag to engage the photoionization edge shift [82] for atomic 
bound-free radiation. (on=l/off=0). Default : .true. 
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Appendix C 


Troubleshooting 


The goal of the Fun 3D developers is to produce as robust a solver as 
possible. However, there are times when the code fails to produce a converged 
solution. For example, taking the square root of a negative quantity (due to a 
negative density or pressure) results in a NaN. We hope that these suggestions 
are helpful. If none of the suggestions listed here remedy your problem, please 
contact Fun3D-Support@lists . nasa . gov. 

C.l What if I cannot run the solver in parallel? 

While the predominant way of executing FUN3D is on parallel architectures, 
the use of MPI for concurrent processing introduces additional complexity. 

It is critical that consistency is maintained between the build and execution 
environments for not only FUN3D but also its dependent third party libraries. 

The consistency holds true for maintaining the same MPI implementation 
and Fortran compiler across the builds and execution. When checking for 
consistency one might use the following in the build environment, 

$ which mpif90 # to show the MPI installation used 

$ mpif90 -show # to show the underlying Fortran compiler used with MPI 

In the execution environment of all hosts, 

$ which mpirun # to show the MPI installation used 

$ which $FC # to show the Fortran compiler and runtime 

The MPI installations and Fortran compilers must agree for successful concur- 
rent execution. 

C.2 What if the solver has trouble starting or reports 
NaNs? 

Check that the freestream, reference, and boundary conditions are specified 
correctly. Visualize the solution, especially near the location of the maximum 
residual. If the problem is widespread, run the simulation again and visualize 
the solution a few iterations before the problem happens. Look for extremely 
large Mach numbers, low pressures, low densities, or reversed flow at bound- 
aries. 
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Examining the residual history may help to isolate the problem to the 
mean flow or turbulence model. Lowering the CFL numbers of the mean- 
flow and turbulence equations can aid linear and nonlinear convergence, see 
section B.4.14. If the linear system is diverging (the linear system can be 
examined with the --monitor_linear command line option), utilize a more 
dissipative flux linearization f lux_construction_lhs or the Krylov projection 
method linear _projection=. true., see section B.4.15. 

Try flow field initialization in the problematic region of the domain (e.g., 
engine plenum), see section B.4.21. Start with some f irst_order_iterations 
(section B.4.9) or try continuation from less challenging freestream condition 
(e.g., lower angle of attack, subsonic Mach number). The time accurate flow 
solver may be able to survive initial transients better than the steady solver. 

C.3 What if the forces and moments aren’t steady or 
residuals don’t converge to steady-state? 

Try lowering the CFL numbers of the mean flow and turbulence model, see 
section B.4.14. Examining the residual history may help to isolate the problem 
to the mean flow or turbulence model. The problem may be unsteady; try 
restarting the solution with a time-accurate simulation. 

C.4 What if the solver dies unexpectedly? 

You may need to set your shell limits to unlimited, 

$ ulimit unlimited # for bash 
$ unlimit # for c shell 

If your operating system reports a Signal 9 or 11 and you have already tried 
removing shell restrictions, you have likely hit the memory limit of your ma- 
chine. Try reducing the number of mesh points, running on more nodes, or 
installing more memory on your machine. 

C.5 What if the compiler complains, “This module file 
was not generated by any release of this compiler”? 

This indicates that you have compiled files from multiple versions of a compiler 
or compilers from different vendors. Use, 

$ make -j clean 

to remove inconsistent files before attempting to re-compile. 
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C.6 What if the solver dies with an error like “Probable 
incomplete read of namelist: &some_namelist” ? 

If this message persists after carefully checking for missing quotation marks, 
ampersands, array indices, etc., try checking for special, non-ASCII characters, 
e.g., cat -v fun3d.nml. 

C.7 What if a segmentation fault occurs after “Calling 
ParMETIS”? 

Make sure that the the width (32 or 64 bits) of integers in Fun3D and 
ParMETIS are consistent. More recent implementations of MPI (e.g., Open- 
MPI) internally manage the handles (i.e. , communicators) differently from 
previous versions of MPI. However, ParMETIS 3.* uses an older paradigm, 
which has been updated in ParMETIS 4.*. Upgrade to ParMETIS 4.*. 

C.8 What if the solver dies with an error like “input 
statement requires too much data” after echoing 
the number of tetrahedra and nodes for a VGRID 
mesh? 

The endianness (section 4.1) of the grid hies (section 4) may be different than 
Fun3D expects. Single-segmented VGRID grids over 20 million nodes exceed 
the allowable record length. Use postgrid to save grid as a multi-segmented 
format (option 05 in batch mode). 

C.9 What if the solver reports that the Euler numbers 
differ? 

The Euler number is a global indicator of consistent node, element, and face 
connectivity. There is some limited evidence that suggests there may be times 
when it reports a problem that may not be an issue for the solver, but the 
failure of the Euler number check indicates a problem with the grid in a ma- 
jority of cases. Instructions to determine if the Euler number will impact your 
solution follow this description of the Euler number. 

C.9.1 Euler Number Description 

A valid grid is composed of four elemental volume types (tetrahedra, pyra- 
mids, prisms, and hexahedra) face-connected either to each other or one of 
two boundary face types (triangles or quadrilaterals). Each boundary edge 
connects to precisely two boundary faces. Two neighboring boundary faces 
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share exactly one boundary edge. For each boundary face connecting to a 
boundary node, every other boundary face connecting to the same boundary 
node can be found by a path through a connected-edge/connected-face traverse 
starting from that boundary face. 

The above restrictions are meant to exclude certain topologies such as two 
spherical boundaries coming together at a point or two rectangular boundaries 
connecting along an edge. These restrictions are not checked explicitly but will 
cause the Euler number check described below to fail. 

The Euler Number computed from boundary data (EN b ) is 

EN b = N b -E b + F b (Cl) 

where 

N b = boundary nodes (counted) (C2) 

E b = boundary edges (inferred from N tri and N quad ) (C3) 

F b = boundary faces (inferred from N tri and N quad ) (C4) 

The Euler number is a characteristic number for the topology of the boundary 
or boundaries. N tr i and N quad are the number of triangular and boundary 
faces, respectively. 

The Euler Number computed from volume data ( EN V ) is 


EN V = 2(N — E + F - C) (C5) 

where 

N = volume nodes (counted) (C6) 

E = volume edges (counted) (C7) 

F = volume faces (inferred from C and F b ) (C8) 

C = volume cells (counted) (C9) 

The formula that is checked is 

EN V - EN b = 0 (CIO) 


Barth [88] derived this formula for tetrahedra and noted the formula does 
not hold in certain cases, such as two simplices that share only one common 
edge or two simplices that share only one common node. Barth notes that the 
above formulas are specific forms of the general Dehn-Sommerville formula, 
reported in Wikipedia to hold for simplicial polytopes and simple polytopes. 
The pyramid is not a simple polytope. It can be proved by induction [89] that 
the formula holds for every valid grid as defined above. 

Try this checklist to diagnose the problem: 

1. Check the EN b with your expectations for this case: 
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2 for a spherical topology, simple 3D wing with symmetry, . . . 

0 for a torus, donut, . . . 

-2 for a double torus, . . . 

-4 for a triple torus, pretzel, . . . 

4 for a sphere within a sphere, . . . 

6 for two spheres within a sphere, . . . 

2. Ensure the number of boundary nodes N b and faces F b reported match 
expected values. 

3. Ensure the number of nodes N and cells C reported match expected 
values. 

4. The difference between EN b and EN V points to inconsistencies in edge 
counts, i.e., 8(E) = 2 (EN b — EN V ) ^ 0. The inequality EN b > EN V 
implies you have more edges than expected. When this occurs, the re- 
ported face counts will differ from an actual count. An error of this type 
would arise when there are adjacent faces that are inconsistent, such as 
a quadrilateral face shared between two elements that is cut into two 
triangular faces by different edges. 

C.9.2 Determining the Impact of an Euler Number Mismatch 

A freestream residual problem localization technique is described. However, 
the best practice is to not proceed without repairing the grid to ensure EN b = 
EN V . The ignore_euler_number namelist variable does just what the name 
implies, and allows the solver to proceed. The --test_freestream option can 
be used as a secondary check on the mesh. On a valid mesh, the solver should 
preserve the freestream for an arbitrary number of iterations. You should run 
20-50 iterations, which may require a lowering of the stopping.tolerance 
to le-20 so the solver does not automatically stop. All residuals should 
hover around machine zero, and not slowly increase (there will be iteration- 
to-iteration variation in the exact number, however). 

If freestream is maintained by this test, you could proceed with your in- 
tended computation using only ignore_euler_number, but this is not recom- 
mended. If freestream is not maintained, this test confirms that there is a 
problem with the mesh and the location of the max residual may give a clue 
as to where in the mesh to start looking for the problem. 
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